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ABSTRACT 



Rapid prototyping is a method of software system development that is gaining 
much support presently. Rapid prototyping allows the designer to quickly produce a 
model of a system or part of a system which the user can see and thus verify if his re- 
quirements have been met. Tlie prototype specifications can then be efficiently con- 
verted to an accurate set of program specifications that the programmers can 
implement as a final working system. The computer aided prototyping system 
(CAPS) is a rapid prototyping system that will automate many of the processes of 
prototyping such as code generation of prototype modules and searching for reusable 
components. 

One of the many components of CAPS is a language translator which translates a 
prototype specification written in the Prototype System Description Language 
(PSDL) into a set of Ada procedures and packages. The Ada procedures and packag- 
es, when executed in proper order, will effectively execute the prototype. This thesis 
demonstrates an implementation of the translator component of the CAPS. An at- 
tribute grammar tool, Kodiyak, is used to build a translator which implements the ma- 
jor constructs of PSDL and produces Ada code to implement PSDL operators 
according to their control constraints. 
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I. INTRODUCTION 



Rapid prototyping is the process of producing a model of a software system to be 
evaluated by the system designer and the system user. It is becoming a widely ac- 
cepted method for software systems design. In a conventional systems development 
cycle tlie system designer and the user work together to determine a set of user re- 
quirements and goals for the complete system. These are eventually converted into a 
set of specifications which can be implemented in a particular programming language. 
If all goes well, the system is implemented according to the specifications and is thus 
a tme implementation of the user’s requirements and goals. 

Unfortunately, systems development is much more difficult than this. Rarely is it 
the case that the designer successfully captures the user’s true requirements. Ordi- 
nardy, the designer is knowledgeable of computer systems and programming but not 
of the user’s specialty. The same holds true of the user, he knows his application and 
how it should operate but he knows very little of computers and their capabilities. 
Consequently, it is difficult to capture the tme requirements of the system for several 
reasons including: 

- The designer is prone to misinterpretation of the user’s goals because they are 
unfamiliar to him. 

- The user often states his goals and requirements in overly general tenns. 

- The user may completely omit other goals and requirements simply because they 
are obvious to liim while they are not obvious to the designer. 

- Because of his unfamiliarity with computer systems and their capabilities, the us- 
er may not Be aware of some features that are available untU later in the project 
as he becomes more familiar with the system. [Ref. 1] 

Whatever the reason, the end result is an incomplete set of requirements that the 
designer must formalize into a set of specifications to be in^lemented in software. 
Programmers implement the system and it is presented to the user but rejected be- 
cause it does not functionally represent what the user thought he wanted in the first 
place. The user points out the discrepancies and then the designer attempts to 
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re-anaJyze the user’s requirements, form an updated set of specifications, then the 
system is re-implemented, and presented again to the user. This software develop- 
ment loop continues until a version of the system is finally accepted by the user. 

Software systems today are becoming extremely large and complex. Utilizing 
methods such as that described above to construct modem software systems results 
in unreasonably long development life cycles and unreliable systems. Productivity 
must be improved to produce such systems in a reasonable amount of time today. A 
method must be found that will allow the user and designer to produce a complete and 
accurate set of requirements prior to code generation of the actual system. Rapid pro- 
totyping is such a method. 

The rapid prototyping loop shown in Figure 1 replaces tlie conventional software 
development process. In rapid prototyping the user and designer still perfonn a re- 
quirements analysis but now a software model of the system, or part of the system, is 
quickly assembled and executed for the user instead of a complete system. The model 
is constmcted knowing that it is probably going to be altered over and over, however 
new models can be produced quickly so the cost of producing the prototype is relative- 
ly cheap. 

The user can evaluate the prototyp>e and point out any discrepancies. The discrep- 
ancies are soon corrected and a new prototype is available for the user to evaluate. 
This prototype loop continues until the user is satisfied with a particular version 
[Ref. 2]. The final prototype can then be used to generate a set of specifications that 
accurately reflect the user’s goals and requirements. Since the programmer is pre- 
sented with an accurate set of specifications, he implements the system once and 
wastes little time perfoiming code corrections as before. Thus productivity and reli- 
ability are greatly enhanced. 

The computer aided prototyping system (CAPS) is a prototyping system intended 
to improve current prototyping methods by automating time consuming tasks in con- 
ventional prototyping such as turning specifications into prototypes, modifying proto- 
types, and searching for reusable components. The components which make up the 
CAPS system include a specification language, an execution support system, a 
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rewrite system, a syntax-directed editor, a software base, a design database, and a 
design management system. 




Figure 1 . Rapid Prototyping Loop 



The specification language (the Prototype System Deswription Language, PSDL) 
allows the designer to formally translate the user’s requirements and concepts into 
specifications. .The sfiecifications can then be used to retrieve reusable software com- 
ponents from the software base. After all of the components of the prototype have 
been retrieved or constructed by the user, they are executed by the execution support 
system (ESS). The ESS is the focus of this thesis. It is composed of three systems, 
the translator, the static scheduler, and the dynamic scheduler. PSDL is an execut- 
able specification language whose execution is a combined effort of the translator, 
static scheduler, and dynamic scheduler. The translator translates the PSDL specifi- 
cations into executable Ada modules while the static scheduler analyzes the PSDL 
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specifications and data-flow dependencies to construct a schedule of operation for the 
set of Ada modules with timing constraints. The dynamic scheduler schedules those 
Ada modules with no timing constraints. [Ref. 3:p. 71] 

Successful execution of a CAPS prototype is dependent on two phases, transla- 
tion and scheduling. The subject of this thesis is the construction of a translator to 
successfully perform the translation phase. The translation process begins with the 
input of a program written in PSDL. The program is parsed into its syntactic con- 
structs, then those constructs are analyzed and Ada code is produced to represent 
them. Translation also means recogirizing built-in PSDL constmets and using reus- 
able generic components to implement the constructs. The objective of this thesis is 
the partial implementation of a translator for the CAPS system. 

An overview of the CAPS system components, the Kodiyak application generator, 
and PSDL are presented in Chapter 11. PSDL constructs and their semantic descrip- 
tions are presented in Chapter III. Tire implementations of PSDL constracts are pre- 
sented in Chapter IV. The implementation of the translation process will be 
presented in Chapter V. Conclusions are presented in Chapter VI. 
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n. BACKGROUND 



A. CAPS OVERVIEW 

The computer aided prototyping system (CAPS) is a rapid prototyping tool pres- 
ently being developed. The objective of CAPS is to reduce a software designer’s ef- 
forts by automating time consuming tasks in conventional prototyping, such as turning 
Sf>ecifications into prototypes, modifying prototypes, and searching for available reus- 
able components. To support this prototyping metliod, several tools are included as 
subsystems of CAPS which are integrated together to form the functional group called 
CAPS. Tire components of CAPS include 

- A specification language. 

- A user interface to speed up design entry and prevent syntax errors. 

- An execution support system to demonstrate and measure prototype behavior and 
to perform static analysis of the prototype design. 

- A design management system to manage reusable software components and de- 
sign data. 

- A software base to store reusable components. 

- A design data base to store the prototype design. [Ref. 3: p. 67-68] 

Figure 2 shows the CAPS system architecture. Following is an overview of the 
functions of each of the components of the CAPS arcliitecturc 

The user interface consists of a syntax-directed editor [Ref. 4] and a graphical ed- 
itor [Ref. 5]. These two tools are used together to generate a design which is free of 
syntax errors as' quickly as possible. The graphical editor allows the designer to en- 
ter his design as a data flow diagram so that relationships between PSDL compo- 
nents can be visualized by the designer and by the user. The syntax-directed editor 
speeds up the process of entering PSDL textual specifications. [Ref. 6:p. 6-7] 

The rewrite subsystem translates the specifications produced in the user 
interface into normalized specifications which can be used by the design management 
system to retrieve components from the software base. Using normalized 
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specifications results in fewer keys to use for the search operation on the data base. 
[Ref. 3;p. 69] 

The design management system [Ref. 7] is an object-oriented database manage- 
ment system. It is responsible for organizing, retrieving, and instantiating reusable 
components from the software base as well as managing versions, refinements, and 
alternatives of prototypes in the design database. It provides special purpose opera- 
tions to compose components, browse the software base, and manipulate the normal- 
ized specifications. [Ref. 3:p. 69] 

The software database is an object-oriented software base containing reusable 
components. The software base provides the ability to browse, select, and retrieve 
components efficiently. The database is searched by providing a normalized specifica- 
tion which can be mapped to one or more software implementations. The entire set of 
retrieved reusable components are then presented to the designer so that he may se- 
lect a choice from the set. [Ref. 3:p. 70-71] 

The execution support system provides the means to demonstrate the actual per- 
formance of the specifications produced in the user interface. There are three compo- 
nents of the execution support system, the translator, the static scheduler, and the 
dynamic scheduler. 

The translator generates Ada code to bind together the reusable components ex- 
tracted from the software database. Its main functions are to implement data streams 
and control constraints [Ref. 3:p. 71]. The output of the translator is a set of Ada 
packages and procedures that can be activated in a specific order to effect execution of 
the prototype. 

The static scheduler [Ref. 8] analyzes the data flow structure and control flow 
structure of the input PSDL program and determines an order of execution, or sched- 
ule, for the PSDL modules which meets the data flow and timing constraints of the 
prototype. 

The dynamic scheduler [Ref. 9] schedules those PSDL modules that have no tim- 
ing constraints. It recognizes when a time slot is available during prototype execu- 
tion and schedules non-time critical modules in those slots. 
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Figure 2. CAPS System Architecture 
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B. PSDL 



The translator’s purpose is to tr 2 inslate a PSDL specification into a set of Ada 
procedures which, when executed in a specific order, will effectively execute the proto- 
type. The translation process is completely dependent on the semantics of PSDL, 

There are several constructs in PSDL that a designer uses to build a prototype 
specification. These constructs include data streams, timers, exceptions, and opera- 
tors. The translator actually budds the operator construct itself during translation, but 
before it can do this, each of the other PSDL constructs must be previously construct- 
ed and available. Construction of a PSDL operator involves instantiating various Ada 
representations of PSDL constructs and manipulating those constructs to provide a 
supporting framework in which a PSDL operator can be simulated. 

1. PSDL Conceptual Model 

PSDL is based on a conceptual model existing as a network of operators and 
data streams. Operators in the network communicate with each other through data 
streams [Ref. 6:p. 11]. An operator is a function which performs a specific user de- 
fined task. It requires a set of input values and produces a set of output values each 
of which may be empty. A data stream is a conduit for moving data values between 
operators. They are tlie source of an operator’s inputs and they are the sink into 
which an operator places its output. 

PSDL can be represented as a computational model described by an augment- 
ed graph 

G = (V, E, T(v), C(v)) 

where V is a set of vertices, E is a set of edges, T(v) is the maximum execution time 
for each vertex v, and C(v) is a set of control constraints for each vertex v. In this 
graph a vertex represents an operator and an edge is a data stream. 

Figure 3 is an example of a PSDL graph with operators. A, B, and C, and data 
streams, a, b, c, d, e, and f, connecting the operators. The graph also indicates timing 
constraints, 10 ms for A and C, 20 ms for B, Control constraints are provided for A 
and B, also. Tlie operator A receives its input data on data stream a, processes the 
data and outputs two results on data streams c and d. This entire process must occur 
in ten milliseconds or less according to the associated timing constraint. 
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Normally, control constraints are not described on the graph because they can 
be numerous and are described textuaUy witliin a PSDL specification. A graph with- 
out control constraints is called an enlianced data flow diagram. [Ref. 3:p. 69] 




Figure 3. Enhanced Data Flow Diagram With Control Constraints 



2. Operators 

Operators in PSDL are either functions or state macliines. A function produc- 
es output whose value is dependent solely on the input values. A state macliine pro- 
duces output whose value depends on the input data values and on internal state 
values. Operators can be triggered by the arrival of input data values on their data 
streams or by a periodic timing constraint which says the operator must fire at a regu- 
lar time interval. 

PSDL operators may also be atomic or composite. Atomic operators represent 
a single operation and cannot be decomposed into subcomponents. A composite oper- 
ator represents the network of subcomponents and data streams into which it can be 
decomposed. [Ref. 6:p. 11-12] 

3. Data Streams 

Data streams represent sequential data flow mechanisms which move data 
between operators. There are two basic types of data streams, sampled and data 
flow. Data flow data streams are similar to first -in-first-out (FIFO) queues with a 
length of one. Any value placed into the queue must be read by another operator be- 
fore another data value is placed into the queue again. Sampled data streams may be 
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considered as a single cell which may be read from or written to at any time and as of- 
ten as desired. [Ref. 6;p. 12-13] 

4. Timing Constraints 

Timing constraints are an essential part of specifying real-time systems. 
They impose an order on operator firing which is based on timing or control flow rather 
than data flow. The three basic types of timing constraints are MAXIMUM EXECU- 
TION TIME, MAXIMUM RESPONSE TIME, and MINIMUM CALLING PERIOD. 
The maximum execution time is an upper bound on the length of time from the instant 
when an operator begins execution to the instant it completes. [Ref. 6:p. 20] 

The maximum response time has two interpretations depending on the type of 
operator it applies to. For sporadic op>erators which have no period, it is an upper 
bound on the length of time between the arrival of one or more new data values on an 
input data stream and the time when the final output value is placed on an output data 
stream in response to the new input values. For periodic op>erators, maximum re- 
sponse time is an upper bound on the time between the beginning of a period and the 
time when the last output value is placed onto a data stream of that operator during 
that period. [Ref. 6;p. 20] 

The minimum calling period is a lower bound for sporadic operators on the time 
between the arrival of one set of inputs 2 ind the arrival of the next set. [Ref. 6:p. 20] 

5. Control Constraints 

Control constraints are the mechanisms which refine and adapt the behavior of 
PSDL operators. They specify how an operator may be fired (by data flow or control 
flow), how exceptions may be raised, and how or when data may be placed onto out- 
put data streams. 

With the exception of timing constraints, all of the features of the PSDL com- 
putational model win be discussed in detail in Chapters III and IV. For a more de- 
tailed discussion on timing constraints see [Ref. 8] and [Ref. 10] 
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C. KODIYAK TRANSLATOR GENERATOR 

Kodiyak is a fourth generation language designed for producing language transla- 
tors and prototyping languages [Ref. ll:p. 1]. It was developed at the University of 
Minnesota and is based on Knutli’s description of attribute grammars [Ref. 12]. 

Very generally speaking, Knuth wrote that a context-free language can be repre- 
sented as a set of grammar mles and that by systematically applying those grammar 
mles to an input string, the input string can be uniquely represented as an abstract 
syntax tree [Ref. 12:p. 127-128]. Knuth goes on to say that attributes can be as- 
signed to the nodes of the abstract syntax tree and tliat the values of the attributes 
can be determined in two ways. 

The first method is by synthesized attributes which assigns values to the at- 
tributes of a node based on the attribute values of the node’s descendants. The sec- 
ond metliod is by inherited attributes where a node’s attribute values are based on 
the attribute values of its parent node. Synthesized attributes are evaluated from the 
bottom up in the abstract syntax tree while inherited attributes are evaluated from the 
top down. [Ref. 12;p. 130] 

The point of Knuth ’s paper is that attributes can be assigned to the nodes of an 
abstract syntax tree and tliose attributes can be defined in terms of other attributes in 
the tree. Thus, the root of the tree can be given an attribute whose value is based on 
the collective values of all the nodes in the tree. That attribute of the root node can be 
used to assign a semantic meaning to the tree [Ref. 12:p. 132] 

Kodiyak puts this theory into practice in three phases. First, it performs a lexical 
analysis on the input string converting it to tokens; second, it parses the tokens into 
an abstract syntax tree; and third, it proceeds to move about the tree evaluating at- 
tributes at each node until aU attributes have been evaluated. The meaning of the in- 
put string can tlien be represented as the coUective value of the attributes at the root 
node. 

Kodiyak is a UNIX-based tool wliich is built on top of two other tools, LEX (a lex- 
ical analyzer tool) and YACC (a parser generator tool). Every Kodiyak program has 
three sections. The first section describes the features of the lexical seamier which is 
used to translate the input source text into tokens. The second section describes the 
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attributes assigned to each grammatical part in the language. Tlie third section de- 
scribes the grammar and attribute equations which are used to determine values of at- 
tributes throughout the tree. [Ref. 1 l:p. 1] 

In the lexical scanner section of a Kodiyak program, rules are given which define 
the token terminal symbols of the source language and their token representations. 
Terminal symbols are defined to be regular expressions and are found in the leaf 
nodes of the abstract syntax tree. Token definitions take the form shown in Figure 4 
where TERMINAL_NAME is the name of the token and REGULAR_EXPRESSION 
is the definition of the token. For example, two lexical definitions used in this thesis 
are 

OPERATOR "operator" I "OPERATOR" 

SOME "by some" I "BY SOME". 

The first definition defines a token named OPERATOR which is created anytime the 
regular expression "operator" or "OPERATOR" is found in the input text. The second 
definition defines a token named SOME wliich is defined anytime the regular expres- 
sion "by some" or "BY SOME" is found in the input text. It is by definitions such as 
these, that Kodiyak reads an input text file and converts it to a stream of tokens. 
[Ref. ll;p. 2-6] 

The attribute declaration section lists all of the non-terminal symbols in the input 
grammar along with the attributes associated with each symbol. The non-temiinal 
symbols are the interior nodes of an abstract syntax tree and are normally found on 
the left side of a typical grammar rule. Kodiyak also allows temiinal symbols to have 
attributes if desired. The statements 

psdl (tm : string;); 

ID I %text : string; 

%line : int; 
value : int; ) ; 

are two examples of attribute declarations. The first statement declares a non-termi- 
nal symbol named psdl wliich has only one attribute named trn of type string. Kodiy- 
ak only supports two primitive types, string and integer. The second example 
declares the attributes for a terminal symbol. An ID token has three attributes, 
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%text which is type string, %line which is type integer, and value which is type inte- 
ger. The %line and %text attributes are predefined in Kodiyak. 



TERMINAL_NAME : REGULAR.EXPRESSION 
Figure 4. Kodiyak Lexical Definition Form 

The %line attribute always contains tlie line number in the input text where the 
associated token was found. The %text attribute always contains the actual text 
which matched the regular expression definition for the token. [Ref. 1 l:p. 2-6] 

The final section of a Kodiyak program is the attribute grammar section. This sec- 
tion defines the syntax and semantics of the translation. It consists of a set of gram- 
mar productions in a fonn similar to BNF and sets of equations defining attributes 
[Ref. ll:p. 8]. The example in Figure 5 is an actual rule used in the translator in tliis 
thesis. It is based on the PSDL grammar rule: 

timer_op ;;= READ I RESET I START I STOP 
where timer_op is a non-tenninal and READ, RESET, START, and STOP are all ter- 
minal tokens. Tlie rule states that a timer_op is recognized if any one of the tokens, 
READ, RESET, START, or STOP is found in the token stream. The associated at- 
tribute equations are enclosed in curly braces for each possible rule. 



timer_op: READ 

{ timer_op.tni = "PSDL_TIMER.READ"; ) 

I RESET 

{ timer_op.tm = "PSDL_T1MER.RESET"; ) 
I START 

{ timer_op.tm = ”PSDL_TIMER.START’’; ) 
I STOP 

{ timer_op.tm = "PSDL.TTMER.STOP"; ) 

1 



Figure 5. Kodiyak Attribute Equation Example 
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The example shows that if timer_op produces a READ token, tlien the trn at- 
tribute of timer_op will be assigned tlie string value of "PSDL_TIMER.READ". 

Without Kodiyak, the implementation of a translator for PSDL would be a much 
more formidable task than it is. EssentiaUy, a lexical analyzer and parser would have 
to be written for PSDL, which are non-trivial tasks, then a tool would be built which 
can traverse an abstract syntax tree and generate code. This would effectively be 
equivalent to writing a compiler for PSDL. Kodiyak allows a programmer to concen- 
trate on the translation process, i.e., attribute evaluation while it handles the compd- 
er-like functions. 
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m, MAJOR PSDL CONSTRUCTS 



The constnicts used in PSDL include operators, data streams, state variables, 
timers, and exceptions. The execution of a PSDL prototype is actually just the inte- 
gration and manipulation of these constructs according to a set of control constraints. 
With the exception of operators, each of these constructs is represented by an ab- 
stract data type in Ada. The following is an informal discussion of the semantics of 
the major PSDL constructs. 

A. DATA STREAM ABSTRACTIONS IN PSDL 

The edges of the PSDL computational model represent data streams. Data 
streams are the mechanism by which two or more operators can communicate 
explicitly. Data streams can carry individual data values of abstract data types, 
values of buUt-in PSDL type EXCEPTION, and values of the built-in data types of 
Ada. Data streams can be described as a pipeline connecting exactly one producer 
with exactly one consumer [Ref 6:p. 12]. 

Figure 6 is an example of a producer operator, opl, connected to a consumer oper- 
ator, op2, by the data stream D. Tlie producer operator has produced the values xl 
and x2 in order. Tlie pipeline property of data stream D dictates that value xl must 
arrive at the consumer operator before value x2 because xJ was created first. Anoth- 
er important property of data streams is that they may carry no more than one data 
value at a time. 

When an operator produces a data value, it writes that value onto a data stream. 
When an operator consumes a data value, it reads that value from a data stream 
[Ref. 13]. 

As implied in the previous paragraph, data streams have operations for reading 
them and writing to them. There is also a third operation for checking them to verify if 
there is a new, or fresh, data value currently on the data stream. 
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There are two types of errors associated with data streams, 
BUFFER_OVERFLOW, and BUFFER_UNDERFLOW. BUFFER_OVERFLOW 
occurs when an operator attempts to write to a data stream that currently has a value 
on it. 

BUFFER_UNDERFLOW is caused when an operator attempts to read a value 
from an empty data stream. Applying the check operation to a data stream will never 
cause either of these two errors because it neither reads nor writes to the data 
stream. [Ref. 13] 

There are two basic kinds of data streams, SAMPLED STREAM and DATA 
FLOW STREAM. A sampled data stream has a continuous nature in that once a da- 
ta value has been written onto it, that data value will remain on the data stream until 
it is overwritten with another value. Even after a value is read from a sampled data 
stream, a copy of that value remains on the data stream and can be read as often as 
needed. [Ref. 13] 

Since data values remain on a sampled data stream after they have been con- 
sumed, it is not possible to have a BUFFER_UNDERFLOW error on a sampled data 
stream after it has been initialized once. In an uninitialized state, sampled data 
streams do not have values on them and therefore the BUFFER_UNDERFLOW er- 
ror could occur if a read operation is performed on the data stream before the first 
write operation. The BUFFER_OVERFLOW error cannot occur on a sampled data 
stream at all because the write operation is always legal on a sampled stream. 

Data flow streams have a more discrete nature about them because they are a 
first-in-first-out data structure. A data value can be written onto a data flow stream 
only if the stream is empty, and conversely, a data value can be read from a data flow 
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stream only if a data value presently exists on the stream. After a data value is read 
from a data flow stream, the stream is left empty. [Ref. 13] 

BUFFER_UNDERFLOW and BUFFER_OVERFLOW can be more easily gener- 
ated in data flow streams than in sampled streams because of their first-in-first-out 
nature. Any attempt to read from an empty data flow stream will cause BUFF- 
ER_UNDERFLOW. Any attempt to write to a data flow stream which currently has 
a value on it will cause BUFFER_OVERFLOW. Because of the ease of generating 
these errors in data flow streams, care must be exercised when using them in a proto- 
typ>e. The timing of the producer and consumer operators must be synchronized so 
that the rate of data consumption on a data flow stream is always equal to the rate of 
data production. [Ref. 6;p. 13] 

Whether a data stream is a sampled or a data flow stream is determined implicitly 
by the context in wliich the stream is used in a PSDL program. Specifically, if a 
stream is used in an operator triggering condition tliat specifies the operator is trig- 
gered BY ALL, then the stream is classified as a data flow stream. (Operators and 
triggering conditions are described in a later section.) All other data streams not so 
used are sampled data streams by default. 

There are four places to declare data streams in a PSDL operator: 

- In an INPUT statement. 

- In an OUTPUT statement. 

- In a STATES statement. 

- In a DATA STREAM statement. 

Data stream, visibility within an operator is somewhat liierarcliical yet it differs 
from the hierarchical visibility rules that may apply in structured languages like Pascal 
or Ada. In PSDL, data streams which are visible in any operator are also visible to 
that operator’s immediate subcomponents but not necessarily to any of its second 
generation descendants. An operator which has a parent operator can selectively 
choose which data streams in its parent to make visible within itself, thus, if it 
ignores any data stream in its parent, that data stream will not be visible to any of the 
current operator’s descendants. 
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INPUT and OUTPUT statements in a PSDL operator specification declare data 
streams used by an operator which are external to that operator. That is, these are 
the data streams belonging to the parent operator which are selected to be visible in 
the child operator. The direction of data flow is dictated by the INPUT and OUTPUT 
statements. An INPUT statement declares that data can only be read from its data 
streams. Likewise, an OUTPUT statement declares that data can only be written to 
its data streams. The forms of the INPUT and OUTPUT statements are shown in 
Figure 7. 

The STATES and DATA STREAM statements are also shown in Figure 7. 
These statements declare data streams that are local to the current operator. The da- 
ta streams declared in the STATES statement are like any other data stream except 
that they are initialized automatically. They are used to carry values of state vari- 
ables which are described later in the discussion of PSDL op>erators. The DATA 
STREAM statement declares all local data streams that do not carry state variables. 

INPUT id_list ; type_name [, id_list : type_name]* 

OUTPUT id_list : type_naine [, id_list : type_name]* 

STATES id_list : type_name LNi riALLY initial_values 
DATA STREAM id_list : type_name [, id_list : type_name]* 

Figure 7. Method of Declaring Data Streams 



B. TIMERS 

In PSDL, a timer is a built-in data type. The timer data type acts as a simple digi- 
tal stopwatch to record elapsed times. The operations available on timers include: 



- RESET 

- START 

- STOP 

- READ 
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Semantically, a timer can be described as a state machine (see Figure 8) having 
three states, an initial state, a running state, and a stopped state. 




In the initial state the timer has a value of zero. All timers are initialized to begin 
in the initial state and thereafter will only return to tlie initial state when the reset op- 
eration is performed. 

The timer transitions to the running state whenever the st 2 irt operation is per- 
formed. The value of the timer in the running state constantly increases with time, 
but its instantaneous value can be obtained by the read operation. 

The stopped state can only be reached from the running state and is done so when 
a stop operation is performed. In this state, the timer is effectively idle and not mea- 
suring elapsed time, that is, its value is constant. 

The value of a timer can always be obtained by the read operation. Note that the 
read operation does not cause a state transition regardless of the state in which it is 
performed. The value of a timer is always the amount of time the timer has spent in 
the running state since the last transition out of the initial state. 

Timers are declared inside a PSDL operator by the TIMER statement whose form 
is shown in Figure 9. It is a simple statement that declares any number of PSDL tim- 
ers inside of an operator. Unlike data streams, timers fully utilize hierarchical visibili- 
ty rules. A timer is visible in the operator in which it is declared and all of its 
subcomponents on all levels [Ref. 6:p. 18]. Presently, an implementation restriction 
in this thesis dictates that timer names cannot be duplicated in a PSDL program. 
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All references to a specific timer name throughout a PSDL program are references to 
the same timer. 

TIMER tl,t2,...,tN 

Figure 9. Timer E>eclaration 

Timer values can be passed along data streams so that a timer’s value can be 
made visible outside of its scope. The timer itself, however, cannot be transmitted 
because it is a state machine, not a value. 

C. PSDL EXCEPTIONS 

PSDL exceptions as described by Luqi in pief. 6] are special data types that may 
be written to any data stream regardless of the stream’s normal data type. When a 
PSDL exception is raised in an atomic operator it is immediately output onto all of the 
operator’s output data streams. This poses a problem in designing downstream oper- 
ators in the data flow. Any time an operator raises a PSDL exception, all operators 
immediately downstream will have a PSDL exception on one or more of their input 
streams. The designer must consider such a case when writing PSDL operators. A 
PSDL system is a network of atomic operators connected by data streams. Actual 
systems could have very complicated networks. Ensuring that the possibility of a 
PSDL exception value is handled everywhere in the system could be a formidable 
task. 

This thesis describes an alternative method for handling PSDL exceptions. The 
principle difference between this method and Luqi’s is that PSDL exceptions are no 
longer allowed to share data streams with normal data values. An operator must 
explicitly declare any external or local data steams which carry the 
PSDL_EXCEPTION data type. The alternate design is intended to modify the origi- 
nal design of PSDL exceptions as little as possible, given the difference stated earlier. 

Requiring operators to transmit PSDL exceptions only on data streams that are 
declared for the PSDL_EXCEPTION data type means that exception communications 
are now explicit. If an operator is allowed to raise a PSDL exception it can only 
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communicate that exception to operators which are directly connected to it via an ex- 
ception data stream. A PSDL exception handler, therefore, is any PSDL operator 
which has an input exception stream declared in the INPUT statement in its PSDL 
specification. The remainder of this section presents PSDL exceptions in temis of the 
alternative method. 

PSDL exceptions are values of a built-in data type called PSDL_EXCEPTION. 
They are used to denote the occurrence of a value or situation that the designer does 
not want to occur during execution of the prototype. For example, the value on a data 
stream may be out of limits or a data stream may not have a value when it is expect- 
ed to have one. The PSDL_EXCEPTION data type has operations for creating an ex- 
ception, raising an exception, and detecting that an exception has been raised. A 
PSDL exception has two states, raised and cleared. A raised PSDL exception is one 
which is active in the same manner that an Ada exception is raised. Conversely, a 
cleared PSDL exception is one that is not raised. 

PSDL exceptions can be raised two different ways. The first is by the 
EXCEPTION statement in an operator’s control constraints. The second method of 
raising a PSDL exception is through an implicit conversion of an Ada exception to a 
PSDL exception. Atomic operators may raise exceptions in the underlying language 
[Ref. 6:p. 19] and the designer has the option of handling the exception in the underly- 
ing language or in PSDL. 

When a PSDL exception is raised it is written to one r>r more data streams. The 
operator which was executing at the time of the exception will be terminated after the 
exceptions have been transmitted. When a PSDL exception is raised in an 
EXCEPTION statement, the designer has control over which streams the exception 
is transmitted. He may selectively choose one or more exception data streams to 
write the exception to. PSDL exceptions raised as a result of an Ada exception are 
not subject to such control. Instead, they are transmitted on aU output data streams 
which are declared to be of the PSDL_EXCEPTION data type. If no output exception 
data streams are available in the operator, there is no way of communicating the con- 
verted exception. In that case, the Ada exception is re-raised and handled elsewhere 
in the execution support system. 
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Exception handling in PSDL is not immediate as in Ada. CAPS places a con- 
straint on prototype execution that adversely affects execution of exception handlers. 
Consider the operation of exception handlers in Ada. When an Ada exception is 
raised, normal execution control flow is interrupted so that an exception handler can 
be located for tlie raised exception and executed. It is both desirable and good lan- 
guage design, that exceptions be handled immediately rather than allowed to linger 
about in a program. In CAPS, however, execution is bound to a scheduled sequence 
produced by the static scheduler and the dynamic scheduler [Ref. 8] which cannot be 
altered. PSDL exception handlers are not given any special consideration by the 
static scheduler; they are simply operators that are scheduled to execute in a pre- 
defined order, they cannot be invoked immediately as they are needed. Thus, PSDL 
exceptions are allowed to be raised but their handling is subject to the static and dy- 
namic schedules of execution. 

Detecting whether a PSDL exception has been raised is a special operation that 
is performed during evaluation of boolean expressions. It is a constmct consisting of 
the data stream name containing the exception, followed by a colon, followed by the 
name of the exception. For example, 

OPERATOR a TRIGGERED IF In_Exception : Out_of_Range 
demonstrates a boolean expression which checks to see if the PSDL exception, 
Out_of_Range, is raised on the data stream called ln_Exception. The data stream, 
In_Exception must have been declared as an input data stream of type 
PSDL_EXCEPTION in this example. 

A PSDL exception is effectively cleared when it is read from a data stream. A 
PSDL exception is read anytime its value is used in a boolean expression other than 
an operator data trigger. 

PSDL exception visibility follows the same rules as data streams. Any exception 
written to a target data stream is visible only to the operators having access to the 
target data stream. 

It is required to include an exception handler in any decomposition wliich is capa- 
ble of producing a PSDL exception. Figure 10 shows an example of this technique. 
The operator. A, decomposes into three operators, B, C, and D. Operator B is 
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capable of raising a PSDL exception, thus it has an exception data stream named er- 
ror connecting it to the operator EH. EH is an exception handler which is triggered 
by the presence of a value on the incoming data stream. The static scheduler will 
schedule EH to execute sometime after operator B, thus handling the error as soon as 
possible and minimizing the time it is allowed to linger in the system. 




D. OPERATOR ABSTRACTIONS IN PSDL 

The vertices of the PSDL computational model represent operators. Until now op- 
erators have been only referred to as producers or consumers, however, there is much 
more to an operator than the fact that it produces and/or consumes data. Operators 
are different from the other constructs in that they are not a PSDL type; instead, oper- 
ators are objects which manipulate the other PSDL constructs in unique ways. How 
an operator manipulates PSDL constructs like data streams, timers, and exceptions 
partially defines the behavior of the operator. 
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1. Operator Classification 

PSDL operators may be cl 2 issified by tliree criteria; 

- Function or state machine operator. 

- Atomic or composite operator. 

- Periodic or sporadic operator. 

a. Functions and State Machines 

Classifying an operator as a function or a state machine depends on wheth- 
er the operator has an internal state. A function operator does not have an internal 
state. It simply consumes its input and produces an output; the value of the output 
def)ends solely on the value of the input. Specifically, a function will produce a one-to- 
one mapping from any set of input data values, xl,x2,...,xN, to a set of output values, 
yl,y2,...,yM. A state macliine, on the other hand, has an internal state which affects 
the values of its output. A state machine will produce a one-to-many mapping from a 
set of input data values to a set of output values. Tlie value of the output data is a 
function of the input data and the internal state. [Ref. 6:p. 15] 

The internal state in a PSDL state machine operator is represented by a 
STATE VARIABLE. Recall that a state variable is a data stream which is automati- 
cally initialized. State variables are declared in a PSDL operator by the STATES 
statement as shown previously in Figure 7. The STATES statement declares a list of 
data streams, which will be local to the current operator, and a list of initial values to 
be placed into the data streams before the prototype begins execution. A state 
macliine can be graphically represented as an enhanced data flow diagram with a self- 
loop as in Figure 11. The self-loop svl is the data stream carrying the state variable. 

b. Atomic and Composite Operators 

This classification depends on how an operator decomposes. Atomic oper- 
ators cannot be decomposed into a lower level of functionality while composite opera- 
tors can be decomposed into a set of lower level operators whose execution as a 
whole simulates execution of the composite operator. Figure 12 shows an example 
of a composite operator. A, and its corresponding decomposition into two lower level 
operators, A1 and A2. Operator A1 is also a composite operator and so decomposes 
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into operators All and A12. Operator A2 is an atomic operator and cannot be decom- 
posed into any lower level of detail. A PSDL program is nothing more than a hierar- 
chical decomposition of a single composite operator into a network of atomic 
operators. The ordered execution of the atomic operators effectively simulates execu- 
tion of the highest level operator. [Ref. 6] 




c. Periodic and Sporadic Operators 

This classifies an operator by its timing constraints. A periodic operator 
has timing requirements which state that the operator must be invoked regularly with- 
in a certain period and that it must complete execution within that period. Sporadic 
operators have no such periodic constraints; instead, they ate required to execute 
when there are fresh data on the input data strecuns. The translator is concerned with 
an operator’s behavior as it executes, not how often it executes or how long it exe- 
cutes, therefore, this classification is irrelevant to the translation process. For a more 
detailed discussion concerning timing constraints and their implementation refer to 
[Ref. 8]. 

2. Operator Control Constraints 

To support real-time systems modeling in PSDL, a powerful set of control con- 
straints are available which impart a specific behavior upon atomic operators. 
Through control constraints several aspects of an operator’s behavior can be speci- 
fied, such as the classification of the operator, the operator’s triggering conditions, 
and the operator’s output conditions [Ref. 13]. The translator is concerned with rec- 
ognizing control constraints that have been placed on an opierator, which are not 
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timing related, and then generating tlie Ada code required to simulate the desired op- 
erator behavior. There are four types of control constraints to be specified; 



- Operator triggering conditions. 

- Exception conditions. 

- Timer conditions. 

- Operator output conditions. 




Figure 1 2. Operator Decomposition 



a. Operator Triggering Conditions 

A triggering condition has two parts, a data trigger and an input guard 
[Ref. 14]. The data trigger is designed to control the initiation of execution of an oper- 
ator based on the presence of new input data values. A new data value on a data 
stream is any data value that has not been read at least once. The input guard is a 
secondary condition which makes an operator’s execution dependent on the values of 
its input data. Tlie triggering condition is a means of specifying data flow control 
among operators. The form of a PSDL triggering condition is shown in Figure 13. 



26 



Triggering_Condition = 

OPERATOR Atomic_Name TRIGGERED Data_Trigger IF Input_Guard 
Figure 13. PSDL Triggering Condition 

Tlie data trigger part of a triggering condition can be further broken down 
into a BY ALL or a BY SOME condition. Referring to the operator model in Figure 
14, the PSDL statement 

OPERATOR opl TRIGGERED BY ALL A,B 
establishes a data trigger on operator opl that allows it to execute only if there are 
new data values on both of the input data streams A and B. The contents of data 
stream C are not considered in the trigger condition. If either A or B does not have a 
fresh data value then the trigger condition is not satisfied and the operator will not be 
allowed to execute at all. 'Phe PSDL statement 

OPERATOR opl TRIGGERED BY SOME A.B 
establishes a data trigger on operator opl that allows it to execute only if there is 
new data on either data stream A or B. Again, the contents of data stream C are not 
considered in the trigger condition and have no effect on it. Conversely, if neither data 
stream A nor B has a fresh data value on it the trigger condition is not satisfied and 
the operator will not execute. 




When a data trigger is satisfied, the operator will initiate execution by con- 
suming the values on all of its input data streams. An unsatisfied data trigger results 
in an operator not executing at all and its data streams are left intact. The data trig- 
ger is an optional feature of the operator triggering condition. A null data trigger 
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effectively always evaluates to true and the operator is allowed to initiate execution 
regardless of the state of its data streams. Care should be taken in such cases not to 
consume a value from an empty data stream. Doing so results in a buffer error and 
the prototype’s execution will be interrupted. 

Assuming that an operator’s data trigger condition is satisfied, the opera- 
tor will consume its input data values and proceed to evaluate the input guard of the 
triggering condition. The mput guard is a boolean expression dependent only upon the 
input values [Ref. 14]. Referring again to Figure 14, consider the PSDL statement 
OPERATOR opl TRIGGERED BY ALL A,B,C IF (A > B) AND(C > 0) 

The operator opl will first read all of its input data streams A, B, and C only if they all 
contain fresh data values. Assuming that the data trigger is satisfied, the operator 
must then evaluate tlie input guard, (A > B) AND (C > 0). If the values of A, B, and 
C satisfy this condition the operator is allowed to commit itself to complete execution 
and perform its function. If the input guard condition is not satisfied, the operator is 
not allowed to execute any farther and is terminated. The data streams will have 
been consumed and will not be restored to their original conditions prior to the trigger 
condition. The input guard is also optional. A null input guard effectively is always 
satisfied and tlie operator will be allowed to commit to complete execution. If both 
the data trigger and the input guard are null, the whole triggering condition is satis- 
fied by default and the op>erator is allowed to execute unconditionally. 
b. Exception Conditions 

The form of the EXCEPTION statement is shown in Figure 15. It consists 
of an exception identifier, an optional target data stream, and an optional exception 
condition. An EXCEPTION statement may specify only a single exception name but 
several EXCEPTION statements may be included in a set of control constraints. The 
target data stream is an output data stream that has been declared to contain a 
PSDL_EXCEPTION type. The exception condition is a boolean expression depen- 
dent on values of input data streams, calculated output data streams, and timers. 
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Exception_Statement = 

EXCEPTION Exception_Name ON Data_Stream IF Exception_Condition 
Figure 15. PSDL EXCEPTION Statement 

The example statement: 

EXCEPTION Out_of_Range ON Excp IF (A<0) AND (A>10) 
will raise a PSDL exception named Out_of_Range if the value of A is not in the 
range from zero to ten, inclusive. This example specifies a target data stream, named 
Excp, onto which the exception value is placed. This statement is used when the de- 
signer desires to explicitly transmit an exception to another operator which will act as 
an exception handler. The data stream, Excp, must have been declared as an output 
data stream or as a local data stream and it must be of type PSDL_EXCEPT10N. 
Had no exception condition been specified, the PSDL exception, Out_of_Range, 
would have been raised unconditionally and output onto the target data stream, Excp. 

It was stated earlier that an atomic operator may also generate exceptions 
in the underlying language. The designer has the option of handling those exceptions 
in the underlying language or he may convert them to PSDL exceptions. When an ex- 
ception is produced in the underlying language (in this case, Ada) and is not handled 
in the atomic operator, an implicit control constraint is placed on the operator wliich 
forces the translator to build an exception closure which can trap the Ada exception 
and convert it into a PSDL exception. To do this, the desirner must declare the Ada 
exception names in the EXCEPTIONS statement in a PSDL op>erator specification. 
Figure 14 shows the form of an EXCEPTIONS statement. It is a simple statement 
which lists one or more exception names which can be raised by an atomic operator. 
For example, a statement such as: 

EXCEPTIONS Out_of_Range, No_Data 

would declare two PSDL exceptions that could be raised by the atomic operator sub- 
components of the operator containing the statement. When an atomic operator rais- 
es any of those exceptions, they will be trapped by the translator’s code and a PSDL 
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exception with the same name wUl be transmitted on aU output streams that are de- 
clared as PSDL_EXCEPT10N streams. 



Exception_Declaration = 

EXCEPTIONS el, e2, ... ,eN 

Figure 16. PSDL Exception Declaration 
c. Timer Conditions 

Timer conditions are control constraints that allow operators to manipulate 
any number of PSDL timers that are visible to them. The form of a timer condition is 
shown in Figure 17. It consists only of a PSDL timer function name followed by the 
target timer name and an optional timer guard. For example, 

RESET TIMER tl IF tl > 45 sec 

is a timer condition which results in the timer named tl being reset when it reaches a 
value greater than 45 seconds. The timer guard in tliis example demonstrates a bool- 
ean operation on the value of a timer. If the condition is not satisfied, i.e., the value of 
tl is less than or equal to 45 seconds, the timer operation is not executed. The timer, 
tl, must have been declared somewhere witliin the current operator’s preceding hier- 
archical structure. Recall that timers are visible in the operator in which tliey are de- 
clared and all of that operator’s subsequent descendants. 

The timer guard is optional and a null timer guard is effectively equivalent 
to a true condition and the timer operation is unconditionally executed. Timer guards 
are boolean expressions which can be dependent on values of operator input data, 
output data, and visible timers. 



Timer_Condition = 

Timer_Op TIMER Timer_Name IF Timer_Condition 
Timer_Op = 

RESET I START I STOP I READ 



Figure 17. PSDL Timer Condition Statement 
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d. Operator Output Conditions 

An output condition takes the fonn shown in Figure 18 and consists of the 
PSDL keyword, OUTPUT, followed by an output data stream name, followed by an 
output guard. The output data stream name must be one of the data streams declared 
in the OUTPUT statement in the operator specification or it may be a local data 
stream declared in a DATA STREAM statement. Unlike timer guards, output guards 
are not optional. The output guard is a boolean expression which def>ends on the val- 
ues of input data, output data, and timer values [Ref. 14]. 



Output_Condition = 

OUTPUT Data_Stream IF Output_Guard 



Figure 18. PSDL Output Condition Statement 



An output condition may be specified for any output data stream, but is not 
required. PSDL does not allow an operator to have more than one output condition 
per output data stream and it is illegal to have an output condition for an input data 
stream. If an output data stream does not have an output condition specified for it, a 
value will always be output to that stream unconditionally during operator execution. 

Normally, output conditions are used when it is desired to restrict the data 
that is placed onto an output stream. To demonstrate the use of output conditions, 
consider the statement 

OUTPUT D IF (D > 0) AND (A = B) 

as applied to the' operator in Figure 14. An output condition is established on opera- 
tor opl’s only output data stream, D. After the operator has executed its atomic 
module and calculated tlie value of D, it may write that value to its output data stream 
only if the output guard condition is satisfied, i.e., (D > 0) and (A = B). If this condi- 
tion is not met, the operator will not write the value of D onto its data stream, other- 
wise it will. Had no output condition been specified for D, the operator would have 
written the calculated value of D onto its data stream unconditionally. 
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IV. IMPLEMENTATION OF PSDL CONSTRUCTS 



A. TRANSLATOR INTERFACES 

The translator is only a single component in the whole CAPS system which must 
be interfaced with other components of CAPS. Specifically, the translator must inter- 
face with the static scheduler, the dynamic scheduler, and the user interface system. 
This section describes the implicit and explicit interfaces with these components. 

1. Translator/Static Scheduler Interface 

The interface with the static scheduler is completely implicit. The static sched- 
uler does not accept input from the translator and produce output based on it; instead, 
the static scheduler makes some assumptions about the structure and contents of the 
translator’s output. The translator produces a set of Ada procedures which represent 
each unique atomic operator in a PSDL program. The static scheduler reads the same 
PSDL program and produces a set of procedure calls into the translator’s output 
which will invoke the atomic procedures in an order sufficient to meet the data flow 
and timing requirements of the PSDL prototype. To make tliis relationship work three 
assumptions were agreed upon by the static scheduler designer and the translator 
designer: 

- Atomic operator procedures adhere to a standard naming convention. 

- Atomic operator procedure calls are parameterless. 

- The translator output will have a standard name. 

a. Atomic Operator Procedure Naming 

When the translator produces Ada code for each atomic operator, it actual- 
ly produces a harness of Ada code into which the actual atomic operator’s code is 
placed. The harness consists of all the Ada code required to implement the control 
constraints on the atomic operators. The single-shot rule [Ref. 6:p. 25] states that 
no operator may be fired more than once inside any one parent composite operator; 
therefore it can be assured that all of the atomic operators in a single composite 
operator will be uniquely named. It is possible, however, that the same atomic 
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operator name may be used in other composite operators in a PSDL program. The set 
of control constraints may vary for each occurrence of that atomic operator. Tlie trans- 
lator would then produce several different procedures because, although the atomic 
code in each procedure is identical, the control constraints may vary and the surround- 
ing harness code will be different in each instance. The problem to be solved in this 
case is how to make each of the atomic operators unique even when they use the 
same atomic name. 

To ensure that an atomic operator procedure would be uniquely named 
even if the actual atomic code inside it has been duplicated elsewhere in the PSDL 
program, a standard naming convention was agreed upon. This standard specifies 
that an atomic operator name will be represented by the concatenation of its parent 
operator’s name, followed by an underscore, followed by the atomic operator’s name. 
An advantage of the naming schema chosen is that the names are meaningful to the 
user and can be lised as is for debugging purposes. 

An alternative solution to this problem is to build a tool which scans a 
PSDL program created in tlie user interface and physically maps each operator name 
to a unique name. The translator and static scheduler could then be guaranteed that 
no name in the entire PSDL input program would be duplicated. There would no long- 
er be any need for a naming convention since all atomic operator names would be 
unique to begin with. Such a tool could easily be constructed using Kodiyak. 
b. Procedure Parameter Passing 

The second concern about the translator’s output was whether or not the 
static scheduler should include parameters inside its atomic operator procedure calls. 
The translator was designed to account for parameters in atomic procedures so that 
the static scheduler could invoke these procedures without regard for their parame- 
ters. The static scheduler only needs to know the name of the atomic operator proce- 
dure and can invoke it with a parameterless procedure call. 

Recall that the translator actually produces a harness for the atomic opera- 
tor’s Ada code. The translator can recognize an atomic operator’s requirements for 
input and output parameters via the input and output data stream declarations in the 
atomic operator’s PSDL specification. All this infonnation is embedded into the 
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harness code as local information so the hsimess procedure itself requires no parame- 
ters. Thus when the static scheduler produces a call to an atomic operator using the 
naming convention described earlier, it is actually calling the harness procedure which 
in turn can call the actual atomic procedure and implement all control constraints asso- 
ciated with that operator. 

c. Package Naming 

After the translator has produced all of the atomic operator procedures re- 
quired, it must package them in a manner that makes those procedure names visible 
to the static schedule. This is easily accomplished by placing the translator’s output 
in an Ada package body. Ada requires that a package body be accompanied by a 
package specification as well. The translator uses the package specification to make 
the procedure names visible to tlie static schedule. The data stream exceptions 
BUFFER_OVERFLOW and BUFFER_UNDERFLOW are also made visible in the 
package specification by renaming the same exceptions from the PSDL_SYSTEM 
package. 

The translator’s output package is called TL and is placed into a file called 
TL.a. The .a extension is required by tlie Ada compiler used in the development of 
this system. The Ada code produced by the static scheduler must utilize the Ada 
with clause to gain visibility to the TL package and all of its procedures as shown in 
Figure 19. 



with TL; 

package STAT1C_SCHEDULE is 
end STATIC_SCHEDULE; 
package body STAT1C_SCHEDULE is 
end STATIC_SCHEDULE; 

Figure 19. Use of Ada With Clause 
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2 . Translator/Dynamic Scheduler Interface 

The interface between the translator and the dynamic scheduler is also an im- 
plicit interface. The issue of concern in this case is a matter of timing. The dynamic 
scheduler calls the time critical atomic operator procedures in the order specified by 
the static schedule. When a time critical operator finishes execution before the end of 
its period the dynamic scheduler will invoke a non-time critical operator during the 
time remaining to the end of that period. Just before the end of the period, the non- 
time critical operator is interrupted, if it is still executing, so the next time critical 
operator can be invoked. To achieve this method of control, Ada tasks are used to im- 
plement the time critical and the non-time critical operators’ schedules. The Ada 
priority pragma is used to establish relative priorities among these tasks such that 
the time critical operators have the higher priority. [Ref. 15] 

Recall that a data stream is a mechanism which allows two or more operators 
to communicate via a single data value. The data stream is therefore a critical section 
which can be accessed by several operators. Any time an operator is performing a da- 
ta stream read or write operation it is inside a critical section and must not be inter- 
rupted. To ensure that a non-time critical Of>erator is not intermpted during a data 
stream operation, all data stream tasks are assigned a higher priority than the time 
critical operators. Tlie actual interface between the translator and the dynamic sched- 
uler is simply an agreement of the task priority values. The non-time critical opera- 
tors are assigned a task priority value of one, the time critical operators are assigned 
a task priority value of three, and data stream tasks have a priority value of five. 

It should be noted that although the priority pragma is a standard feature of 
any validated Ada compiler, the values that may be assigned in the pragma are imple- 
mentation defined and could very possibly range from zero to zero. Thus, using this 
pragma to assign varying priority values makes the execution support system imple- 
mentation dependent. 

3. Translator/User-Interface Interface 

The interface in this case is a combination of solid interface specifications and 
assumptions. The user-interface is described in detail in [Ref. 16]. There are six is- 
sues to be dealt with m the translator’s interface with the user-interface: 
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- Syntactically correct PSDL source code. 

- No duplicated composite operator names. 

- Command line invocation of the translator. 

- Atomic Ada code is inserted into the PSDL source code. 

- User-defined types are placed at beginning of PSDL text. 

- The first PSDL operator after the user-defined types is the root operator. 

a. Syntactically Correct PSDL Source Code 

The translator depends on the user-interface for its input PSDL source 
code. The user-interface produces the PSDL source code via the syntax-directed edi- 
tor and the graphical editor. The first interface issue is an assumption that the PSDL 
source code produced in the user- interface is syntactically correct. The translator ap- 
plication generated by Kodiyak includes its own PSDL lexical analyzer and parser. If 
the input PSDL source code is not syntactically correct, the translator will terminate 
abnormally and ungracefully. Since this termination is built into the code produced by 
Kodiyak it cannot be controlled. 

b. Duplicated Composite Operators 

Tills issue is related to the standard naming convention used in the trans- 
lator/static scheduler interface. In fact, that naming convention is dependent upon this 
interface issue. The single-shot rule [Ref. 6:p. 25] prevents the duplication of any op- 
erator name, composite or atomic, in a single set of child operators. That is, given any 
PSDL operator it is guaranteed that that operator name will not duplicate any of its 
sibling operator names and that its cliildren, if any, will all have unique names. 

Tills does not guarantee that operator name duplication will not occur 
among different branches of the PSDL liierarchical decomposition tree. Figure 20 
shows an example in which a composite operator is used twice during execution of 
the prototype. The single-shot rule is maintained throughout the decomposition. Ac- 
cording to standard hierarchical scoping rules, a name can be duplicated in two differ- 
ent scopes and represent two different objects. K that is tlie case in this example, 
and the operator D represents one operator in B’s decomposition while D represents 
a different operator in C’s decomposition, the translator will fail. The translator will 
assume that both instances of operator D are instances of the same operator and it 
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will only produce one set of atomic operator procedures to avoid a name conflict. 
Thus, if D was intended to name two different operators in different scopes, only one 
of those operators would have been produced and the Ada code generated by the 
translator would be semantically incorrect. This condition cannot be allowed to occur 
so an assumption is made that there are no duplicated composite operator names in a 
PSDL source code input to the translator. This possibility for failure can be eliminat- 
ed by using the same naming conventions for composite operators as for atomic 
operators. 




c. Invocation of the Translator 

Tlie translator is an executable block of code that is activated by a UNIX 
command line entry. There are two interface issues involved here, the name of the 
translator command and the set of command line options available. The translator’s 
name is simply translator. To invoke the translator at the UNIX prompt type 

translator [options] filename -o TL.a 

where options are any of the set of legal command line options shown in Table 1 [Ref. 
ll:p. 206]. Filename is the name of the PSDL input source file, and -o sends the out- 
put of the translator to the file named TL.a. Normally, none of the command line 
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options should be selected except the -o option. See [Ref. 11] for a more detailed dis- 
cussion of Kodiyak translator options. 

TABLE 1. TRANSLATOR COMMAND LINE OPTIONS 

-h Print out a list of legal options. 

-file Read input from file rather than the standard input. 

-e Continue attribute evaluation even after an error occurs. 

-1 Print out tokens as tliey are scanned. 

-y Print out all grammar rule reductions as they occur. 

-L Turn on LEX’s debugging features. 

-Y Turn on YACC’s debugging features. 

-c Generate a core image when a run-time error occurs. 

-s Print out storage statistics after all attribute evaluation is complete. 

-o file Divert the standard output to file. 



d. Insertion of Atomic Ada Code Into PSDL Code 

Originally, no provision was made for importing the actual reusable Ada 
code required to implement an atomic opierator. The PSDL source code specified only 
the Ada procedure name in the software database. For example, 

IMPLEMENTATION Ada filename 

specifies tliat the atomic operator, filename, is stored in the software database and is 
to be used to implement this operator. The method of getting the reusable module 
from the software base and into the translator was not clearly defined. 

It was agreed that the IMPLEMENTATION statement in an atomic oper- 
ator’s implementation would be exploited to make the actual Ada code visible to the 
translator. When the reusable module is retrieved from the software base it is insert- 
ed into the PSDL source code at the IMPLEMENTATION statement. It can easily 
be inserted by the retrieval system and then it can easily be extracted by the transla- 
tor and placed in the TL.a package produced by the translator. 
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The PSDL grammar required a slight modification to the IMPLEMENTA- 
TION statement to implement this feature. It is now 

IMPLEMENTATION Ada filename | source ) 
where source refers to the actual Ada code retrieved from the software database. 
The source code must be bracketed by curly braces so the translator recognizes it as 
a comment and not as additional PSDL code. 

€. User-Defined Types 

Currently, user-defined types in PSDL have not been implemented. In an- 
ticipation of their implementation, it was decided that the layout of an input PSDL 
program would list all of the user-defined types at the top of the input file. This is so 
that during translation, a symbol table can be built for the user-defined types prior to 
their use in the PSDL program. In addition, a user-defined type must be located prior 
to any instance of its use in any other user-defined type. This follows very closely to 
the style of other conventional block stmctured languages like Pascal or Ada. 
f. Root Operator 

Recall that a PSDL program is a decomposition of a single operator into its 
components. The highest level composite operator in a PSDL program is called the 
root operator and it represents the system being prototyped. TTie operators in a 
PSDL program are listed after all of the user-defined types and the translator is de- 
pendent upon the order of appearances of the operators. The root operator must ap- 
pear before all other operators in the input file. After the root operator appears the 
only constraint on operator order is that any composite operator must appear before 
any of its subcomponent operators. 

4. Translator/Software Base Interface 

The translator implicitly interfaces with software base in that it expects the re- 
usable software components to be Ada procedures. Any other type of Ada construct 
will cause the translator to fail. This is an implementation restriction and it is antici- 
pated that future versions of the translator will allow various Ada constructs to be 
used as reusable components. 
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B. ADA IMPLEMENTATIONS OF PSDL CONSTRUCTS 

The following sections describe the actual Ada packages and procedures used to 
implement each of the major PSDL constructs described in Chapter HI. The data 
stream, exception, and timer constructs are pre-defined Ada packages and are resi- 
dent in an Ada package called PSDL_SYSTEM. This package contains all of the 
built-in type declarations in PSDL as weU as the buffer errors that can be generated. 
Operator constructs are not resident anywhere because they are the results of 
translation. The aim of the translator is to produce the Ada code which realizes 
PSDL operators. Appendix A contains the Ada source code for each of the implemen- 
tations performed in this thesis. 

1. Data Stream Implementation 

Data streams are implemented as an Ada generic package containing an em- 
bedded task. Data streams are critical sections because they are referenced by sev- 
eral operators simultaneously, thus an Ada task is required for their implementation. 
Ada makes no provision for generic tasks so to get around that constraint, tasks are 
embedded inside of generic packages. Inside the task are the various operations that 
must be allowed on data streams to implement things like data triggers and data 
stream reads and writes. 

Four separate packages were constructed to implement the four variations of 
data streams. They include: 

- FIFO. a which implements a standard data flow stream. 

- SAMPLED.a which implements a standard sampled data stream. 

- FIFO_STATE_VAR.a which implements a data flow state variable data stream. 

- SAMPLED_STATE_VAR.a which implements a sampled state variable data 
stream. 

All of these data stream implementations use the same data structure shown 
in Figure 21 to represent the data stream. It is a simple Ada record structure con- 
sisting of two boolean flags to indicate , first, if the data stream is initialized, and sec- 
ond, if the data on the stream is a new value. The last field in the data stream record 
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is used to hold the value which resides on the data stream. This field takes the type 
established in the generic instantiated of the data stream package, 
a. Sampled Data Streams 

Tlie GET operation first checks the data stream’s initialized flag and if it is 
set it will copy the value of the data stream into the formal parameter. If the 
initialized flag is not set, then the data stream has not yet executed a write (or PUT) 
operation and a BUFFER_UNDERFLOW exception is raised. Anytime the GET op- 
eration successfully reads a data value, the new__data flag will be cleared. 

The PUT operation is always successful in a sampled data stream. It will 
copy the value of the formal parameter into the data stream. The initialized flag and 
the new_data flag are always set after a PUT operation. 



type DATA_STTIEAM is 
record 

INITIALIZED, 

NEW_DATA : BOOLEAN; 

VALUE ; ELEMENT_TYPE; - Generic input type 

end record; 

Figure 21 . Data Stream Record Structure 

The CHECK operation simply looks at the new_data flag and returns its 
value. It indicates whether or not the data stream has a new data value on it. 
CHECK is accessed by a function named FRESH. Ada will not allow functions inside 
of tasks, thus the FRESH function exists outside of the embedded task and invokes 
the CHECK procedure inside tlie task. FRESH returns true only if there is fresh data 
on the data stream. 

b. Data Flow Data Streams 

The GET operation is identical to the sampled data stream GET operation 
described above except that it will raise BUFFER_UNDERFLOW if the new_data 
flag is clear, that is, the buffer does not contain new data. 

The PUT operation first checks the new__data flag and, if it is set, will raise 
the BUFFER_OVERFLOW exception. If the new_data flag is clear then tlie input 
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formal parameter value will be copied into the data stream and the new__data flag 
set. 

The CHECK operation simply returns the value of the new_data flag. The 
presence of data on the data flow stream is determined by the value of the new_data 
flag. If it is tme, then there exists a data value on the data stream; if it is false, then 
no data value effectively exists on the data stream. The FRESH function is imple- 
mented here in the same manner as it is in the sampled data stream implementation. 
It is the FRESH function which actually accesses the CHECK operation. 
c. State Variable Data Streams 

State variable data streams are almost identical to their standard data 
stream counterparts. A state variable data stream must be instantiated with an ini- 
tial value and because of this, its initialized and new_data flags wiU be initialized to 
tme. Other than this exception, a sampled state variable and a data flow state 
variable data stream are identical to a standard sampled and data flow data stream, 
respectively. 

An alternative method of implementing the state variable data stream is to 
use the nomial data streams with no changes. The initial value of the state variable 
could be placed in the data stream by a PUT operation prior to the execution of the 
prototype. This method was not used in this tliesis because it would require slightly 
more evaluation to be perfonned by the Kodiyak when building the translator. 

2. PSDL Exception Implementation 

The Ada enumerated data type was selected to represent the 
PSDL_EXCEPnON data type. The PSDL.EXCEPTION type actually does not 
exist until compile (or translation) time. The translator is designed to scan tlie entire 
PSDL input program and collect all of the declared PSDL exceptions. Once the excep- 
tion names are collected, the translator constructs a type declaration for the 
PSDL_EXCEPnON type. The type declaration looks like 

type PSDL_EXCEPnON is (namel, name2, ... ^lameN); 
where namel ... nameN are the unique exception names used in the input PSDL pro- 
gram. The PSDL_EXCEPTION type is declared so that it is visible to aU of the oper- 
ator procedures constmcted by the translator. 
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The implementation of a data stream to be used as an exception data stream 
is not constructed in this thesis. A firm definition of PSDL exceptions and their se- 
mantics has not been reached. The ideas presented in this thesis concerning PSDL 
exceptions are still only concepts which have not been realized. 

To implement exception data streams, a package similar to the FIFO.a imple- 
mentation is required. The new_data flag can be used to indicate if an exception is 
raised or not. A set flag implies a raised exception; a cleared flag implies a cleared 
exception. The PUT and GET operations should also be modified so they do not gen- 
erate any buffer errors. 

An exception cannot overwrite another exception value that is currently active, 
or raised. When the PUT operation is invoked on an exception data stream that is 
carrying an active exception, it should discard the new exception value and return nor- 
mally. The concept being enforced here is that the first exception generated has 
highest priority on a data stream until it is cleared. A data stream exception is 
cleared when the GET operation is performed. 

The FRESH function should be replaced with a function called ACTIVE. The 
ACTIVE function takes a single argument, a PSDL_EXCEPT10N type, and returns 
true if the argument is currently in the data stream and has not been read. 

3. PSDL Timer Implementation 

Timers are implemented as a generic package containing the timer data struc- 
ture and the operations necessary for the timer state machine described in Chapter 
in. The timer data structure is shown in Figure 22 and contains four fields: 

- START_TIME. Time when the last start operation was initiated. 

- STOP_TIME. Time when the timer was last stopped. 

- ELAPSED_TIME. Eliqjsed time accumulated up to the last stop operation. 

- PRESENT_STATE. The present state (running, stopped, or initial) of the timer 
state machine. 

The timer package uses the Ada CALENDAR package to gain access to the 
system clock and built-in time manipulation arithmetic such as subtracting the start 
time from the system clock’s current time to get an elapsed time. The timer package 
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expects all time values to be in miliiseconds since that is the default in PSDL. The 
translator automatically converts all time expressions in the PSDL source code to mil- 
lisecond expressions. 



type STATE is (INITIAL, RUNNING, STOPPED); 


type TIMER is 




record 




START TIME, 




STOP TIME 


: CALENDAR.TIME; 


ELAPSED TIME 


: DURATION; 


PRESENT_STATE 


: STATE := INITIAL; 


end record; 





Figure 22. PSDL Timer Data Stmcture 



4. PSDL Operator Implementation 

Unlike the other major PSDL constmcts, PSDL operators do not have a stan- 
dard generic package ready to be instantiated. The implementation of operators is 
not a straight-forward process that can be performed by a single piece of Ada source 
code. An operator is a set of PSDL constructs and a set of PSDL control constraints 
that dictate how to manipulate the PSDL constructs in the current operator, as well 
as those constructs in any liigher-level operators that are visible, like timers. The 
implementation of the PSDL operator is the translator’s single most important 
function. 

The design of a PSDL operator implementation was driven by the semantics of 
PSDL and by the needs of the static scheduler. The PSDL semantics determined the 
use of Ada control structures to implement PSDL control constraints. The static 
scheduler drove the choice of structure for an Ada implementation of a PSDL opera- 
tor. The static scheduler requires a set of simple procedures which can be called in a 
specific order to effectively execute the prototype. An added requirement of the static 
scheduler is that the procedures must also be executed according to a set of timing 
constraints. The static scheduler must have total control over the execution of an 
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atomic operator. Allowing the static scheduler to call a composite operator procedure 
which then calls its own subcomponent procedures implies that necessary timing con- 
straints and operator precedence constraints would be determined and implemented 
by the translator itself. It would have to ensure that such constraints were built-in to 
tlie translation. 

Doing this obviously defeats the purpose of tlie static scheduler and places an 
unnecessary requirement on the translator. Therefore, the static scheduler must de- 
termine all timing and precedence constraints and apply them to only the atomic oper- 
ators in a PSDL program. Only by scheduling the atomic op>erators can the static 
scheduler be guaranteed full control over timing constraints. The requirement placed 
on the translator, then, is to produce a set of stand-alone procedures that the static 
scheduler can schedule individually and have confidence that only a single atomic op- 
erator will be executed at a time. 

Meeting that single requirement is a key issue in this thesis. Doing so means 
that a PSDL specification which is hierarchically structured must be broken down into 
a set of stand-alone procedures having a flat structure. The problem with a flat struc- 
ture is that nonnal visibility and scoping mles associated with a hierarchical structure 
no longer exist, yet there are rigid visibility rules tliat must be maintained in a PSDL 
operator. To meet this requirement, it was decided that a composite operator would 
be translated into a specification package containing all local PSDL construct instanti- 
ations and lines of visibility to all parent operator constructs. The lines of visibility 
are accomplished through the use of the Ada with and renames constructs. 

This method is best explained by example. Appendix B is a sample PSDL 
system which performs no particular function. The example consists of an enhanced 
data flow diagram, the corresponding PSDL source code, and Ada translation. For 
brevity, only the shaded portions of the enhanced data flow diagram will be dis- 
cussed. Operators Cl, C2, and C3 are composite operators while Al, A2, A3, and A4 
are atomic operators. Operators C2 and C3 are subcomponents of Cl; operators Al 
and A2 are subcomponents of C2; and operators A3 and A4 are subcomponents of 
C3. Beginning at the root, the data streams visible in operator Cl are its local data 
streams a, b, c, and d. PSDL rules of visibility say that all of the data streams visible 
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in Cl are also visible in its subcomponents, C2 and C3. Examination of the PSDL 
specification of operator C2 reveals that C2 requires visibility of data streams a, b, c, 
and d in its parent, and a local data stream, e. Likewise, op>erator C3 requires 
visibility to data streams a, b, c, d, and its own local data stream f. The atomic op>era- 
tor A1 requires visibility to data streams a and e; atomic operator A3 requires visibili- 
ty to data streams c and f. 

During translation, a specification package would be generated for each of the 
composite op>erators and in this example they would all contain nothing but data 
stream package instantiations because data streams are the only type of PSDL con- 
structs used in this example. The specification packages for op>erators Cl, C2, and C3 
are shown in section C of Appendix B. All the static scheduler is concerned with at 
this time is the set of procedure drivers used to implement only the atomic proce- 
dures. In this example procedures C2_A1 and C3_A3 are two of those procedures. 
(Tlie names used in this example are the actual names produced by the translator. 
Naming conventions are described in Chapter IV, section A.) 

Procedure C2_A1 would be activated when the static scheduler wants to in- 
voke atomic operator Al. Recall that operator A1 must have access to data stream e 
in its parent operator C2, and it must access data stream a in operator Cl. To do tliis 
procedure C2_A1 must use the Ada with clause, 

with C2_SPEC; 

to gain visibility to everything tliat operator C2 can access. Notice that package 
C2_SPEC also uses a with clause, 

with Cl.SPEC; 

so that it may gain access to all of its parent op>erator’s data streams. Using the Ada 
with clause in this manner is the first step taken to establish a line of visibility from 
an atomic op>erator to its desired PSDL constracts. 

The second step is in the use of the Ada renames clause. Looking at proce- 
dure C2_A1, the statement 

DSa.GET(TL_a); 

is a data stream procedure call. It sp>ecifies that the value of variable TL_a is to be 
written onto data stream DSa. DSa is a package and GET(TL_a) refers to a 
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procedure call witliin that package. But, which package does DSa really refer to? Be- 
cause there is no DSa package declared inside procedure C2_A1, Ada will attempt to 
look elsewhere for the package. The only place to look is in the C2_SPEC package 
because of the with clause associated with C2_A1. Inside package C2_SPEC, a 
package named DSa is indeed found, however, that DSa package is part of the 
renames clause, 

package DSa renames Cl_SPEC.DSa; 

That means any reference to the DSa package inside of package C2_SPEC is actually 
a reference to the DSa package inside C1_SPEC. Following that link up to C1_SPEC, 
we see that the DSa package inside C1_SPEC is the original data stream that was 
declared in composite operator Cl. Thus, the combination of Ada with and renames 
clauses has created a link, or line of visibility, from the actual data stream manipula- 
tion inside procedure C2_A1 up to the ancestor operator where the data stream 
actually resides. The overall result is that procedures C2_A1 and C3_A3 exist as 
stand-alone procedures in a flat stnicture that can be called in any order desired by 
the static scheduler. It can be guaranteed that each of those procedures has access 
to all of its required PSDL constructs no matter where those constructs exist in the 
hierarchical PSDL specification. 
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V. TRANSLATOR CONSTRUCTION 



A. MODIFYING PREVIOUS WORK 

After the implementations of data streams, timers, and exceptions were complet- 
ed, attention was turned toward producing an implementation of PSDL operators us- 
ing Kodiyak. This was the most significant task performed in this thesis. Previous 
work by Moffitt [Ref. 17] and Janson [Ref. 10] produced an incomplete Kodiyak pro- 
gram upon which this translator was based. Moffitt’ s Kodiyak program was capable 
of parsing only PSDL programs with no boolean or arithmetic expressions. 

The PSDL grammar was designed without any syntactic rules for expressions. It 
was assumed that expression implementations would be dependent upon the underly- 
ing language used for the PSDL translation and therefore the syntactic rules for ex- 
pressions in the underlying language could be inserted in the PSDL grammar. 
Moffitt’ s Kodiyak program implemented only the general PSDL grammar in Luqi’s 
dissertation with no capability for parsing expressions. 

Implementing the Kodiyak translator in this thesis began with modifying Luqi’s 
PSDL grammar so that it would include limited Ada expressions. Appendix C con- 
tains the updated PSDL greunmar used in this thesis. Only boolean expressions 
were included in the updated version of PSDL because implementing the entire range 
of Ada expressions in the Kodiyak proved to be too time consuming. 

Once the grammar was completed, Moffitt’ s Kodiyak was modified to accommo- 
date the new grammar. The process of modifying and installing the PSDL grammar 
was performed in conjunction with Marlowe and the static scheduler because the stat- 
ic scheduler uses Kodiyak as well to translate PSDL into a form consistent with its 
needs. At this point a version of Kodiyak existed which could successfully read and 
parse a PSDL program, however, it performed a null translation. By performing a null 
translation, the Kodiyak program was effectively a template whose attributes and at- 
tribute equations could be modified as needed to produce any desired translation of 
PSDL. 
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B. THE KODIYAK PROCESS 

Chapter II provided a brief overview of the Kodiyak translator generator and its 
purpose. Kodiyak is used in this thesis to convert a PSDL program into an abstract 
syntax tree (AST). Once in a tree structure the PSDL program can be scanned for in- 
formation about its hierarchical structure and its functionality. Two complete passes 
down and up the AST are required to produce an Ada translation of a PSDL program. 

Information about a PSDL program is stored in a Kodiyak map data type. The 
map type is the only high level data type offered in Kodiyak. The map type consists of 
a finite set of pairs which describe a function. A map pair consists of a key and an im- 
age such that the key is mapped into the image [Ref. ll:p. 12]. Maps are used in the 
translator to map a PSDL operator name into information about its structure, content, 
and context much like a symbol table is used in a compiler. Some of the items stored 
in maps include: 

- Whether an operator is composite or atomic. 

- The parent of an operator. 

- An operator’s input and output streams. 

- Data stream types. 

Figure 23 shows an example of an AST based on the PSDL grammar productions: 

start -> psdl 

psdl -> component psdl I null 
component -> operator I data_type. 

This small subset of the PSDL grammar is suitable for providing a high level view of a 
psdl program structure in an abstract syntax tree. 

Movement through the AST is described in terms of passes. A pass through the 
AST consists of either beginning at the root of the tree and proceeding down until all 
of the leaves have been visited, or beginning at the leaves of the tree and proceeding 
up to the root. In either case a pass is a one way trip through the tree. 
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Figure 23. PSDL Abstract Syntax Tree 



Pass one of the translator begins at the root of the AST, labelled START in Figure 
23, and proceeds down the tree in a depth-first order. The first PSDL module in the 
tree is a user-defined data type. Kodiyak will scan that module first, gathering infor- 
mation about the data type and storing that information in a map somewhere in the 
DATA_TYPE node. The second PSDL module in the tree is a PSDL operator. 
Kodiyak will scan this module just as it did for the user-defined type, storing all of the 
pertinent data about the operator in a map inside the OPERATOR node. The first 
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pass is complete when the last PSDL node has been scanned. Some of the useful in- 
formation collected at this point includes: 

- Every operator name and its parent. 

- Every data stream name, type, and classification as a sampled or data flow 

stream. 

- All exceptions declared in the program. 

However, all of this information is still segmented. The information in any single 
OPERATOR node is known only inside that node. To be useful for translation, all of 
the individual information maps distributed throughout the tree must be collected and 
their contents must be merged into a single map. 

Pass two begins at the bottom of the tree in the leaves and proceeds up. The very 
last PSDL node in Figure 23 is an empty node. It is a result of the empty production 

psdl -> null 

and therefore contains no information. The information collection process actually be- 
gins with the next-to-last PSDL node since the last node is essentially empty. The 
information maps in each of the PSDL node’s children are merged into a single map in 
the PSDL node. The PSDL node then routes its combined information map up to its 
own parent PSDL node. In this manner all of the maps in each leaf node of the AST 
are bubbled up to the root of the AST. After the START node has collected all of the 
information from its children, it is left with a collection of data which represents the 
entire PSDL program in a single map. This map contains ail of the contextual data 
about the PSDL program in the AST. 

Pass three begins at the root of the tree in the START node. Translation can begin 
now that contextual information is available for the entire tree. The presence of global 
context data is equivalent to possessing foreknowledge about the future of the PSDL 
program as well as remembering its past. The global map in the START node is rout- 
ed down the tree to each PSDL node. Translations are made at each node of the tree 
based on the data in the global map. 

These translations are strings of Ada code. As translations are made, they are 
stored in a map in the leaves of the tree. At the end of pass three, the individual 
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translations of each PSDL node have been formed but they are still segmented just as 
the context data was at the end of pass one. 

Pass four begins at the leaves of the tree and proceeds up to the START node. 
Now the individual translations are gathered from each PSDL node and combined into 
composite groups of translated Ada code. Eventually, all of the translation informa- 
tion is combined in a single node at the root of the tree. 

The translation information can then be placed into slots of the TL package tem- 
plate, which is described later. The filling of the TL package template effectively pro- 
duces the TL package which is the final output from the translator. The TL package 
represents the Ada translation of the PSDL program in the AST. 

C. TRANSLATION OF PSDL EXPRESSIONS 

Before describing the overall translation process, attention should be devoted to 
the translation of PSDL expressions. PSDL expressions appear in a variety of PSDL 
statements and the translation of those statements involves the translation of 
expressions. 

A PSDL expression is a simple boolean expression with two operands and a bool- 
ean operator. A PSDL condition is a complex PSDL expression, that is, any PSDL 
condition can be parsed into a group of one or more PSDL expressions joined by bool- 
ean operators. The translation of a PSDL condition involves the translation of each of 
its component expressions. 

The PSDL grammar (shown in Appendix C) has been modified from the original 
grammar in [Ref. 6] to handle boolean expressions. A PSDL condition is a boolean 
expression dependent upon values of data streams, timers and exceptions. PSDL ex- 
pressions are divided into three classes of expressions: 

- Timer expressions. 

- Exception expressions. 

- Normal expressions. 
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1. Timer Expressions 

Timer expressions are designed to allow two timers to be compared with each 
other or to allow a single timer to be compared with a constant time value. Figure 24 
shows the forms of timer expressions. PSDL timer visibility rules require that a timer 
name used in any timer expression must be visible in the current operator or a higher 
level ancestor operator. 

Timer constants represent a simple time value. They may be expressed as a 
positive integer followed by an optional time unit. Time units may be specified as mil- 
liseconds, seconds, minutes, or hours with milliseconds being the default units. 



Timer_Expression = 

timer_name rel_op timer_name 
I timer_name rel_op time_constant 

rel_op = < I <= I > I >= I = I /= 
time_constant = integer unit 
unit = ms I sec I min I hours 

Figure 24. PSDL Timer Expression 

Timer expressions are translated to boolean expressions in Ada utilizing func- 
tion calls into the timer packages. The generic timer package is shown in Appendix 
A. For example, the expression 

Timer 1 < Timer2 

translates to the Ada expression 

Timerl.READ < Timer2.READ 

where the READ function returns the present value of a timer in milliseconds. 

Timer expressions with constants are straight forward translations also. For 
example, the expression 

Timerl > 45 min 

translates to the Ada expression 

Timerl.READ > 2700000. 
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The Kodiyak program itself recognizes time units and converts all time con- 
stants in a PSDL program to milliseconds. In the example above, 45 min is translated 
to an equivalent value of 2,700,000 milliseconds. 

When the PSDL grammar was modified to parse boolean expressions, it was 
patterned after the expression grammar of Ada. Therefore, PSDL foUows the same 
precedence rules as Ada; the NOT operator has highest priority, foUowed by the 
AND and OR operations, followed by the relational operators. Parenthesized expres- 
sions will be given highest priority in any expression. 

When using timer expressions, there is a semantic subtlety which the design- 
er must be aware of. Timer expressions attempt to perform real-time operations, 
however, the computer system being used for development of this translator is a sin- 
gle-CPU machine. Expressions are evaluated left to right, sequentially. Consider the 
case when evaluating a timer expression like 

Timerl =Timerl. 

In real-time, the expression is always true because a timer is always equal to itself. 
The Ada translation of this expression is 

Timerl. READ = Timerl. READ 

which is an expression of two calls to the READ function. The evaluation of this ex- 
pression is performed sequentially, left to right. If the first function call occurs at time 
t, the second function call must occur at time t + d where d is at least the time re- 
quired to perform the first function call. If the value of d is significantly small, the dis- 
creetization error will compensate for the time difference and the two function calls 
will return the same value. On the other hand, if d is sufficiently large (greater than 
one half of one millisecond) the values returned by the function calls will be different 
and the expression will always be false! 

Ideally, either the Ada compiler or the translator should recognize this kind of 
situation and optimize it. Presently, the translator makes no consideration at all for 
optimization. 

2. Exception Expressions 

An exception expression is of the form shown in Figure 25. The purpose of 
PSDL exception expressions is to check for the presence of a particular PSDL 
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exception on a data stream. Figure 26 shows an example of an exception expression 
and its Ada translation. The expression evaluates to true if a PSDL exception named 
exceptionX is currently active on the data stream named StreamX. StreamX must be 
an input data stream whose type is PSDL_EXCEPTION. 



Exception_Expression = 

Data_Stream_Name : Exception_Name 

Figure 25. PSDL Exception Expressions 

The expression is translated to a function call, ACTIVE, which returns a bool- 
ean value indicating if its PSDL exception argument is currently active. The ACTIVE 
function will clear the exception if it returns a true value, otherwise the exception val- 
ue currently on the data stream is left alone. The use of exception expressions any- 
where within an operator implicitly makes that operator an exception handler. 



PSDL: 

StreamX : exceptionX 

Ada Translation: 

EXStreamX.ACnVE (psdl_exceptionX); 

Figure 26. PSDL Exception Expression Example 

3. Normal Expressions 

A normal expression is a PSDL expression involving only normal data 
streams or constants. The form of a normal expression is shown in Figure 27 along 
with some examples of normal expressions. 

The stream names used in any PSDL expression must be visible to the atomic 
operator containing the expression. The translator presently has no means of per- 
forming its own visibility checking or type checking in a PSDL program. It is anticipat- 
ed that a static semantic analyzer for PSDL could be constructed to perform such 
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checks prior to sending a PSDL program to the translator. Such a tool could guarantee 
static correctness of the PSDL input to the translator. 



Normal_Expression = 

data_stream_name rel_op data_stream_name 
I data_stream_name rel_op constant 
I constant rel_op data_stream_name 

rel_op = < I <= I > I >= I = I /= 

Figure 27. PSDL Normal Expression 

The translator can only handle scalar data types in normal PSDL expressions. 
This is a constraint imposed by the limited expression parsing capability given to the 
PSDL grammar in this thesis. The user must ensure that data streams and constants 
used in PSDL expressions are type compatible because their translations are subject 
to the strong typing of Ada. The addition of user-defined types in future versions of 
the translator will require modifications to PSDL’s expression handling capabilities. 

Currently, the Ada translations of normal expressions consist of Ada variables 
and constants. The translator will declare a variable for each data stream used in a 
normal expression. Variables are required because atomic PSDL operators consume 
their input data stream values once during execution, however, data stream values 
can be used any number of times in the same operator. The data stream value is 
stored in a variable so that it may be referenced as often as needed without having to 
read the data stream more than once. 

Figure 28 shows three examples of normal expressions that may be found in 
any PSDL condition. Translation A in Figure 28 shows the data stream variable dec- 
larations that would be generated to accommodate the expression translations shown 
in translation B. The variables are declared using the same type of their correspond- 
ing data streams. If Streaml were a data stream of type FLOAT, its associated vari- 
able, TL_Streaml, would be declared as a FLOAT variable. 
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Note the naming convention used to name data stream variables. It concate- 
nates the string "TL_" to the front of the data stream name. This is done to avoid 
naming conflicts. 

The three basic types of PSDL expressions described in this section are the 
building blocks of PSDL conditions. Since all three expression types produce boolean 
results, they can be used together in a single PSDL condition as in the statement 
OUTPUT a IF (a > 0) AND (t < 5 min) OR (excp : no_data) 
which uses an expression of all three types. 



PSDL: 

Streaml < Stream2 
Streaml > 10 
10 = Streaml 



Ada Translation:. 

TL_Streaml < TL_Stream2 
TL_Streaml > 10 
10 = TL_Stream2 



Figure 28. Normal Expressions and Their Translations 



D. THE TL PACKAGE 

The final output of the translator is an Ada package named TL. A template de- 
scription of the TL package is shown in Figure 29. The TI package embodies all the 
Ada code necessary to simulate the atomic operators in a PSDL program. It is de- 
signed to provide visibility to all of the atomic operator drivers and to the Ada excep- 
tions which are to be handled by the dynamic scheduler/debugger. All other 
implementation specifics are hidden from the static and dynamic schedules. 

The Kodiyak translator generator [Ref. 11] was used to produce an executable 
program which translates an input PSDL file into the TL package. The source code 
used for the Kodiyak program is contained in Appendix D and is quite lengthy. It is 
not the intention of this thesis to describe the Kodiyak program line-by-line. Rather, 
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package TL is 

type PSDL_EXCEPnON is (psdl_excpl, psdl_excp2, ... , psdl_excpN); 
excpl, excp2, ... , excpN : exception; 

procedure atomic_driverl; 
procedure atomic_driver2; 

procedure atomic_driverJ; 
end TL; 

with PSDL_SYSTEM; 
use PSDL_SYSTEM; 

package body TL is 

atomic procedures drawn from software base 



PSDL operator specification packages 



PSDL atomic operator driver procedures 



end TL; 

Figure 29. TL Package Template 
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the concepts of the translation process will be discussed by describing the formation 
of the TL package. 

The Kodiyak program itself was constructed incrementally by selecting a small 
section of the TL package and programming a Kodiyak program to produce the transla- 
tion for that section. Once the Kodiyak program could produce that section, a new sec- 
tion of the TL package was selected and the existing Kodiyak program was modified 
to produce the new section as well as the previous one. This incremental process 
continued until a fmal Kodiyak program existed which could produce the whole TL 
package. The TL package is divided into five major sections: 

- Exception declarations. 

- Atomic operator driver headers. 

- Atomic procedures. 

- PSDL operator specification packages. 

- PSDL atomic operator driver procedures. 

These five sections represent the portions of the TL package which are derived 
from the PSDL input program. The exception declarations section defines the 
PSDL_EXCEPTION data type and all of the PSDL exceptions that may be raised in 
the PSDL program. The atomic operator driver headers section lists the procedure 
names which are to be called by the static and dynamic schedules. This section is a 
requirement of Ada packages to ensure visibility into the actual atomic operator driv- 
ers in the package body. The atomic procedures section contains all of the Ada proce- 
dures drawn from the software base. The PSDL operator specification packages 
section contains all of the composite operator specifications. These specifications are 
represented as Ada packages containing only data stream and timer instantiations. 
The last section contains all of the procedures used to implement the atomic operator 
drivers. It is these procedures that are called by the static and dynamic schedules. 

1. PSDL Exception Declarations Section 

This section of the TL package declares the PSDL_EXCEPTION type and all 
of the PSDL exceptions that are found in the PSDL input program. The 
EXCEPTIONS statements in all of the PSDL specifications are used to generate the 
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translation to place in this section. An example of an EXCEPTIONS statement is 
shown in Figure 30 along with the translations that are derived from it. 

The EXCEPTIONS statement declares all the Ada exceptions that can be 
raised by an atomic operator. These exceptions must be captured by the ESS and 
converted to PSDL exceptions. 

Exception names in a single EXCEPTIONS statement may not be duplicated, 
however, an exception name may be included in any number of different 
EXCEPTIONS statements throughout a PSDL program. Recall that exception names 
are unique in PSDL, so that references to the same name in two or more 
EXCEPTIONS statements actually refer to the same PSDL exception. 



PSDL: 

EXCEPTIONS excpl, excp2, ... 

Ada Translation A: 

type PSDL_EXCEPTION is (psdl_excpl, psdl_excp2, ...); 

Ada Translation B: 

excpl, excp2, ... : exception; 

Figure 30. EXCEPTIONS Statement Translation 

There are two parts to the translation of the EXCEPTIONS statement. The 
first part, translation A in Figure 30, places the exception names into a map. This map 
will be combined with the exception name maps of other atomic operators to generate 
a single list of PSDL exception names. To avoid naming conflicts, each exception 
name in the EXCEPTIONS statement is prepended with the string "psdl_" when 
placed into the map. At the end of pass four in the translator, the combined exception 
names are used to generate the PSDL_EXCEPTION type declaration as shown in 
Figure 30. This type is an Ada enumerated data type where the enumerated items 
are the unique exception names retrieved ftx>m the map. 

Translation B in Figure 30, generates the Ada exception declarations. These 
are the actual exceptions raised by the atomic components from the software base. 
The names in the EXCEPTIONS statement are not altered when translated into Ada 
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exception declarations. Like their PSDL counterparts, Ada exceptions used in a 
PSDL program are unique. Multiple references to the same exception name refer to 
the same exception regardless of location in the PSDL source code. 

2. Atomic Operator Driver Headers Section 

This section is a requirement of Ada, not of PSDL or CAPS. Visibility to the 
objects contained inside an Ada package body are determined by the package specifi- 
cation [Ref. 18:p. 7-1]. It is desired to provide visibility only to the exceptions which 
could be generated by a PSDL program and to the atomic operator drivers. The state- 
ments in this section are simply the procedure headers of the atomic operator drivers 
with no bodies. 

The atomic operator driver headers are produced during the third pass of the 
Kodiyak program. Figure 3 1 highlights the portions of the PSDL program which deter- 
mine these translations. When processing the PSDL statement, 

OPERATOR Sub_Operator_Name TRIGGER Triggering_Condition, 
the contextual data from pass two is used to identify Sub_Operator_Name as an 
atomic operator or composite operator. If it is atomic, a procedure header will be gen- 
erated for it by concatenating the strings "procedure", Parent_Operator_Name, 
Sub_Operator_Name, and Parent_Operator_Name is known from the 

OPERATOR statement in the PSDL specification section. The concatenated string is 
stored in a map. If there are any more atomic subcomponents in the current operator, 
their procedure headers will be stored in the map also. If Sub_Operator_Name is a 
composite operator, no procedure header will be generated oecause composite opera- 
tors are not executable and therefore do not require a driver. 

During pass four of the Kodiyak, all of the atomic operator driver headers are 
collected into a single string which is then placed into the atomic operator driver head- 
ers section of the TL package. 

3. Atomic Operators Section 

This section of the TL package contains a set of Ada procedures which are the 
reusable components drawn from the software base. The user interface inserts these 
procedures into a PSDL program before it is sent to the translator. Figure 32 high- 
lights the PSDL statement used to derive this section. 
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Translation of Atomic_Source is more of a cut and paste operation than a 
translation process since Atomic_Source is already in Ada code. During pass one, 
Source_Code is collected in its entirety and placed into a map. Pass two then collects 
all of the various Atomic_Sources in the PSDL program and combines them into a sin- 
gle map item. The translation is effectively complete at the end of pass two. 

The single map item representing all of the atomic procedures as a whole is 
placed into the atomic operators section of the TL package at completion of pass four. 



OPERATOR Parent_Opwator_Name 

SPECmCATION 

END 

IMPLEMENTATION GRAPH 
Link Statements 
DATA STREAM ... 

TIMER ... 

CONTROL CONSTRAINTS 

OPERATOR Sub_Operator_Name 

TRIGGER Triggering_Condition 
CONSTRAINTS 

END 

Figure 31. Statements Used to Build Atomic Procedure Header 

4. PSDL Operator Specification Packages Section 

This section contains a set of Ada package specifications. There is an Ada 
package specification for every composite operator in a PSDL program. Each specifi- 
cation package can be represented by a template with various slots. The specification 
package template in Appendix E was derived to guide the development of the Kodiy- 
ak program. It is a template of an Ada package specification with slots to fill in. 
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OPERATOR Atomic_Operator 

SPECinCATION 

END 

IMPLEMENTATION ADA Atoinic_Operator {Sbu^jCode} 

END 

Figure 32. Statements Used to Build Atomic Operator Header 

The translator must map certain PSDL statements into the slots in the specifi- 
cation package template. The slots in the specification package template represent 
data stream and timer instantiations. Since these packages only serve to declare da- 
ta structures, no accompanying package bodies are required. The slots of the specifi- 
cation package teihplate are: 

- Package header slot. 

- Input / output stream instantiations slot. 

- State variable data stream instantiations slot. 

- Local data stream instantiations slot. 

- Local timer instantiations slot. 

a. Package Header Slot 

This slot names the current operator’s package and its parent operator’s 
specification package. The Ada code which fills the slot is formed by translating the 
PSDL statements shown in Figure 33. 

There are two ways to translate a PSDL operator specification header into 
the specification package header. Translation A in Figure 33 shows the most 
common translation, it contains an Ada with clause. Parent_Operator_SPEC is the 
name of the specification package belonging to the parent of Current_Operator. By 
"withing" the parent specification package, the current operator is given a line of visi- 
bility into it so that the current operator may access any external PSDL constructs in 
its parent operator. 
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The name given to the specification package being formed is simply the 
name of the current composite operator, Current_Operator in this example, concate- 
nated with the string ”_SPEC". 

Translation B is a special case and only applies to the root operator. The 
root operator has no parent, therefore there is no need to use a with clause. The only 
translation to perform is the package name which is identical to the procedure just de- 
scribed in Translation A. 



PSDL; 

OPERATOR Current_Operator 
SPECmCATION 



Ada Translation A: 

with Parent_Operator_SPEC; 
package Current_Operator_SPEC is 
Ada Translation B: 

package Current_Operator_SPEC is 

Figure 33. Operator Specification Header Translation 

b. Input /Output Stream Instantiations Slot 

This slot contains data stream package instantiations corresponding to the 

data streams listed in the INPUT and OUTPUT statements of a PSDL operator speci- 
fication. Figure 34 shows an example of each and their translations. 

The INPUT and OUTPUT statements describe the external inputs and 
outputs to and from an operator. To the translator, they indicate the particular data 
streams visible in the parent operator which should also be visible inside 
Current_Operator. 

The names used in the INPUT and OUTPUT statements must replicate 
names used in the parent operator. For example, if a parent composite operator owns 
two data streams named X and Y, and an atomic child operator wants to use X as an 
input stream and Y as an output stream, then the atomic child must use the names X 
and Y in its INPUT and OUTPUT statements. If a data stream name is used in an 
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INPUT or OUTPUT statement which is not used in the parent operator, then a se- 
mantic error results which will cause the translator to rename a package that does not 
exist 

The translation of an INPUT or OUTPUT statement is simply a renaming 
of a data stream package which can be found in the parent operator’s specification 
package. All data stream packages are named by prepending the letters "DS" to the 
stream names listed in the INPUT and OUTPUT statements. 

It was decided during the design of the translation, that an INPUT or 
OUTPUT statement used in the root operator would be semantically incorrect. The 
root operator represents the highest level operator in the system, in fact it is the sys- 
tem. As such, there are no external operators to communicate with the root, there- 
fore there should be no external inputs or outputs to or from the root. 



PSDL: 

INPUT Stream 1, Stream2 : type_name 

OUTPUT Streams, Stream4 ; type_name 



Ada translation: 

package DSStreaml renames 
package DSStream2 renames 
package DSStreamS renames 
package DSStream4 renames 



Parent_Operator_SPEC.DSStreaml 
Parent_Operator_SPEC.DSStream2 
Parent_Operator_SPEC.DSStream3 
Parent_Operator_SPEC.DS Stream4 



Figure 34. INPUT, OUTPUT Statement Tr. nslations 



c. State Variable Data Stream Instantiations Slot 

This slot contains the Ada code required to instantiate state variable data 

streams. The STATES statement in a PSDL operator specification is the source of 
translation. Figure 35 shows an example STATES statement and its translation. 

The STATES statement declares local internal state variables inside 
Current_Operator. To the translator, these are new state variable packages which 
must originate inside Current_Operator’s specification package. 
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The names used in the STATES statement must not duplicate any data 
stream names used in an INPUT, OUTPUT, or DATA STREAM statement. Such an 
occurrence would cause the translator to generate two data stream packages with the 
same name in the same specification package. The Ada compiler will not allow this. 

The items in initial_value_list must be scalar constants compatible with 
type_name. Arithmetic constant expressions are not aUowed in this version of the 
translator because arithmetic expressions are not a part of the PSDL grammar. Fu- 
ture versions may implement this feature. The number of initial values in the initial 
value list must be at least one. The first initial value will be associated with the first 
state variable; the second initial value is associated with the second state variable, 
and so on. If there are more initial values than state variables, the extra initial values 
are ignored. If there are fewer initial values than state variables, the last initial value 
in the list is assigned to all state variables without a corresponding initial value. For 
example, the statement 

STATES A,B,C,D : INTEGER INITIALLY 0,1 
would assign a value of zero to state variable A and a value of one to state variables 
B, C, and D. 

State variables are translated into new instantiations of state variable da- 
ta streams with an initial value as shown in Figure 35. Because they are data 
streams, the standard data stream naming convention of prepending "DS" to the 
stream names in the STATES statement is used. Whether the state variable is in- 
stantiated as a sampled or data flow data stream depends on the use of the data 
stream in lower level operators. Recall that only data streams used in a BY ALL 
trigger condition are data flow streams, all others are sampled streams. Since the 
classification of the data stream is dependent upon its context, this translation cannot 
be performed before pass three of the translator. 

d. Local Data Stream Instantiations Slot 

This slot contains the Ada code required to instantiate new data streams 

which are local to the current operator. These instantiations are translations of the 
DATA STREAM statement found in a PSDL operator implementation. Figure 36 
shows an example of a DATA STREAM statement and its translation. 
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PSDL: 

STATES Stream5, Stream6 : type_name INITIALLY initial_value_list 



Ada translation: 

package DSStreamS is new SAMPLED_STATE_VAR (type_name,initial); 
package DSStreamti is new DATAFLOW_STATE_VAR (type_name, initial); 



Figure 35. STATES Statement Translation 



The puipose of the DATA STREAM statement is to declare local data 
streams in a composite operator which may be used by its subcomponent operators. 
The rules for input, output, and state variable data stream names apply to local data 
streams as well. The names declared in a DATA STREAM statement cannot dupli- 
cate any other data stream names declared in a higher level operator, i.e., there can- 
not be two different data streams with the same name in a PSDL program. 



PSDL: 

DATA STREAM Streaml, Stream2, .. : type_name 



Ada Translation: 

package DSStreaml is new SAMPLED_STREAM(type_name); 
package DSStream2 is new DATAFLOW_STREAM(type_name); 



Figure 36. DATA STREAM Statement Translations 



A DATA STREAM statement is translated into a set of data stream pack- 
age instantiations.' Because the data streams are local, they must be instantiated 
using the Ada new statement instead of the renames statement used for data 
streams in INPUT and OUTPUT statements. Whether to declare the data stream 
package as a sampled or dataflow stream is dependent upon the stream’s context. 
The context is not known until pass two of the translator and the translation is not 
performed until pass three. 
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e. Local T inter Instantiations Slot 

This slot in the specification package template contains the Ada code re- 
quired to instantiate timer packages. Figure 37 shows an example of a TIMER state- 
ment and its translation. 

The Ada code in the timer instantiations slot comes directly from the trans- 
lation of the TIMER statement. The translation itself is performed during pass three 
of the translator, however, it could just as well have been performed in the first pass 
because there is no dependence at all upon the context of the timer. 

To avoid naming conflicts, the translator prepends the string "TM_" to all 
timer names as shown in Figure 37. 

After all of the slots in the specification package template have been filled 
with Ada code, they are concatenated together to form a single Kodiyak string which 
is the specification package. That string is placed into a map and will be collected and 
combined with all of the other specifications packages in the PSDL program. This fi- 
nal collective group is placed into the PSDL operator specification packages section of 
the TL package template. 



PSDL: 

TIMER tl, t2, ... 



Ada Translation: 

package TM_tl is new PSDL_TIMER; 
package TM_t2 is new PSDL_TIMER; 



Figure 37. TIMER Statement Translation 

5. PSDL Atomic Operator Driver Procedures Section 

This section of the TL package contains a set of Ada procedures which act as 
drivers for the procedures drawn from the software base. Each of the procedures in 
this section implements an atomic operator in terms of its PSDL control constraints. 
These procedures are constructed during passes two, three, and four of the Kodiyak 
program. A driver procedure must be built when the Kodiyak is processing a 
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composite PSDL operator which has atomic subcomponents. It is in this situation 
when the Kodiyak has access to the information required to build the driver proce- 
dure. That information includes: 

- The atomic operator name. 

- The parent operator name. 

- The atomic operator’s control constraints. 

The construction of a driver procedure can be patterned after the implementa- 
tion template shown in Appendix E. The implementation template is a partial Ada 
procedure with seven slots to be filled in. The translator must map certain PSDL 
statements into each of these slots to perform a successful translation. The slots to 
be filled in are; 

- A header slot. 

- A data stream variable declaration slot. 

- A triggering condition slot. 

- An atomic procedure call slot. 

- A control constraints slot. 

- An unconditional output slot. 

- An exception closure slot. 

Following is a description of how various PSDL statements are interpreted and trans- 
lated into Ada code in the implementation template. 
a. Header Slot 

Slot one is the header slot. To fill this slot, the translator must generate 
an Ada with clause, and Ada use clause, and the procedure name. The with and use 
clauses import the parent operator’s specification package. This gives the atomic 
operator driver access to any data streams and timers that were visible in the parent 
operator. The procedure name of the atomic operator driver is constructed by concate- 
nating the parent operator name and the atomic operator name with an underscore 
character between them. 

The translation required to fill this slot is performed during pass three of 
the Kodiyak. The set of PSDL statements used for the translation are highlighted in 
Figure 31. The upper highlighted statement specifies the name of the parent operator; 
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the lower statement names the atomic subcomponent If the subcomp>onent in the 
lower statement is a comp>osite operator, no translation is performed for it. Compos- 
ite operators are not executable, therefore they do not have an atomic procedure for 
which a driver must be constructed. The with and use statements in the header slot 
are formed by concatenating the parent operator name in the upper highlighted state- 
ment in the figure with the string, "_SPEC;". Using the generalized PSDL operator in 
Figure 31, the translation of the highlighted statements appears as 
with Parent_Operator_SPEC; 
use Parent_Operator_SPEC; 

procedure Parent_Operator_Name_Sub_Operator_Name is 

end Parent_Operator_Name_Sub_Operator_Name; 
b. Data Stream Variables Slot 

Slot two is the data stream variables slot. This slot declares Ada vari- 
ables which will be used to physically interface an atomic operator with its data 
streams. The statements which contribute directly toward the translation of the data 
stream variables are the INPUT and OUTPUT statements in an operator specifica- 
tion. The INPUT and OUTPUT statements determine the variables needed to make 
a procedure call to the atomic Ada code. 

Consider the INPUT and OUTPUT statements in Figure 38. If these state- 
ments belong to an atomic operator’s specification, then they can be interpreted as 
the input and output parameters to the atomic procedure. However a, b, c, x, y, and z 
are all data streams in the PSDL specification but the procedure must be called with 
actual parameters as in 

Atomic_Procedure_Call (TL_a, TL_b, TL_c, TL_x, TL_y, TL_z); 

When the translator scans an atomic operator’s INPUT and OUTPUT statements, the 
stream names in those statements and their types are stored in a map during pass 
two. Later, when the atomic driver procedure is being formed, those stream names 
can be recalled from the map along with their types and translated into variable 
declarations as shown in Figure 38. To avoid name conflicts, variable names are 
formed by prepending the string "TL_" to the data stream name. 
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c. Triggering Condition Slot 

Slot three in the implementation template is to be filled with the triggering 
condition translation. Triggering conditions were described in Chapter HI. The form 
of an atomic operator’s triggering condition is shown again in Figure 39 along with the 
form of its translation. The translation of a triggering condition involves the transla- 
tion of its data trigger and input guard as shown in Figure 40. 

Triggering conditions are translated into Ada conditionals (If-Then state- 
ments) where the conditions to be evaluated are the Ada translations of the data trig- 
ger and input guard. The input guard is nothing more than a PSDL condition and is 
translated as described previously in section C. The data trigger checks for the pres- 
ence of new data values on its data stream arguments. The FRESH function of the 
data stream implementation is used to realize a data trigger, recall that the FRESH 
function returns true if there is a new data value on its data stream, otherwise it re- 
turns false. Figure 40 shows that a data trigger can be a BY ALL or a BY SOME 
trigger. The BY ALL trigger requires fresh data on all of its data stream arguments. 
This type of trigger is translated into a series of boolean function calls joined by the 
Ada AND operator. The BY SOME trigger requires fresh data on at least one of its 
data stream arguments. It is translated into a series of boolean function calls joined 
by the Ada OR operator. 

Both the data trigger and the input guard may be null conditions. In each 
case a null condition is translated to a boolean constant value of true so the condition 
will always be satisfied during execution. 

Embedded within the translation of a triggering condition is a translation to 
read data stream values. This is a semantic requirement of PSDL; recall that if a data 
trigger is satisfied, a PSDL operator will consume its data stream input values. The 
PSDL statement required for this translation is the INPUT statement of the atomic 
operator’s PSDL specification. Figure 41 shows an example of an INPUT statement 
and its corresponding translation into data stream read operations. The GET proce- 
dure of the data stream implementations are used to implement this requirement. 
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PSDL: 

INPUT a, b, c : type_name 
OUTPUT X, y, z : type_name 



Ada Translation: 

TL_a : type_name; 
TL_b : type_name; 
TL_c : type_name; 
TL_x : type_name; 
TL_y : type_name; 
TL_z : type_name; 



Figure 38. Data Stream Variable Translations 



PSDL expressions are translated into Ada boolean expressions whose op- 
erands are data stream variables, timers, or exceptions. If any data stream variables 
are used in a PSDL operator, the data stream read translation is necessary to ensure 
those variables have initial values. Only the input data stream variables need to be 
initialized, the output data stream variables are initialized by the atomic procedure 
when it is called by the atomic procedure driver. 



Triggering_Condition = 

TRIGGERED Data_Trigger IF Input_Guard 



Ada Translation: 

if Data_Trigger_Translation then 
Read Input Streams 
if Input_Guard_Translation then 

end if; 
end if; 



Figure 39. PSDL Triggering Condition Translation 
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Data_Trigger = 

BY ALLidl,id2, ... 

I BYS0MEidl,id2,... 
I null 

Input_Guard = 

PSDL_Condition 
I nuU; 



Ada Translation: (Data_Trigger) 

DSidl. FRESH and DSid2.FRESH 
DSidl. FRESH or DSid2.FRESH 

Ada Translation: (Input_Guard) 

refer to section C, Translation of PSDL Expressions 



Figure 40. PSDL Data Trigger and Input Guard Translation Forms 
d. Atomic Procedure Call Slot 

Slot four of the implementation template is filled with an Ada procedure 
call. The procedure being called belongs to the group of reusable components drawn 
from the software base. Each atomic procedure driver calls one of those atomic proce- 
dures. The translation of the atomic procedure call is generated from the INPUT and 
OUTPUT statements of the atomic operator’s PSDL specification. The data streams 
in these statements correspond to in and out parameters in an Ada procedure. The 
exception to this is for data streams of type PSDL_EXCEF^TION. PSDL exceptions 
are not permitted to be used as parameters for an atomic procedure. Exceptions 
raised in atomic procedures are Ada exceptions which the translator is responsible for 
converting into PSDL exceptions and transmitting on PSDL_EXCEPTION data 
streams. 

When the translator scans the INPUT and OUTPUT statements of an 
atomic operator, the data stream names are collected into a map entry which is the 
parameter list to be used in the atomic procedure call. During pass three of the trans- 
lator, this map entry is retrieved and converted into a procedure call when an atomic 
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operator is being scanned. Figure 42 shows an example of the PSDL statements re- 
quired to produce an atomic procedure call. The name used for the atomic procedure 
call is the exact name given in the statement 

OPERATOR Atomic_Name TRIGGERED .... 



PSDL: 

INPUT X, y, z : type_name 

Ada Translation: 

DS x.GET (TL_x); 

DSy.GET(TL_y); 

DSz.GET(TL_z); 

Figure 41 . Data Stream Read Translation 
e. Control Constraints Slot 

Slot five of the implementation template is a collection of translations of 
timer operations, exception operations, and conditional output operations. Timer op- 
erations can be directly translated into Ada if-then statements. The three timer oper- 
ations and their translations are shown in Figure 43. The timer condition is a PSDL 
condition and is translated as described in section C. Timer operations are translated 
into procedure calls to timer packages. Examination of the PSDL grammar in Appen- 
dix C shows that the timer condition is optional. If a null timer condition is specified, 
the translator will interpret it as a boolean constant of value, true. The constant true 
value will force the Ada if-then translation of a timer operation to always execute. 
For example, the timer operation 

START TIMER tl 

will translate to the Ada if-then statement 

if true then 
tl. START; 
end if; 

which will always execute. 
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PSDL: 

OPERATOR Atomic_Name 
SPECinCATION 

INPUT a, b, c : type_name 
OUTPUT X, y, z : type_name 

END 

IMPLEMENTATION ADA Atomic_name {Source_Code} 
END 



Ada Translation: 

Atomic_Name (TL_a, TL_b» TL_c, TL_x, TL_y, TL_z); 



Figure 42. Atomic Procedure Call Translation 



Exception operations are also direct translations. Figure 44 shows the 
forms of an Exception operation and its translation. Exception operations have only a 
single form, however the exception condition is optional. If an exception condition is 
specified, the EXCEPTION statement will be translated into an Ada if-then 
statement. The exception condition is a PSDL condition and is translated as 
described in section C. The exception operation is translated into a data stream PUT 
procedure call. To be semantically correct, the data stream must have been declared 
as a PSDL_EXCEPTION, if not, then a type mismatch will occur during compilation of 
the Ada translation. 

The translator handles a null exception condition in the same way a null 
timer condition is handled. The condition_translation is a boolean constant of value, 
true. The Ada if-then statement representing the EXCEPTION statement will 
always execute if the exception condition is null. 

When the concept of PSDL exceptions was being designed, it was desired 
to have PSDL exceptions behave as closely as possible to Ada exceptions. The Ada 
return statement shown in the translation of a PSDL EXCEPTION statement is an 
attempt to meet this requirement. The overall function of the EXCEPTION statement 
is to place a PSDL exception onto a data stream and then terminate execution of the 
atomic operator. The return statement achieves this effect. 
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PSDL: 

STOP TIMER tl IF Conditionl 
START TIMER tl IF Conditionl 
RESET TIMER tl IF Conditions 



Ada Translation: 

if Condition l_Translation then 
tl.STOP; 
end if; 

if Condition2_Translation then 
tLSTART; 
end if; 

if Condition3_Translation then 
tl. RESET; 

end if; 



Figure 43. PSDL Timer Operation Translations 



The final control constraint to be translated is the conditional output 
statement. The forms of the conditional output statement and its translation are 
shown in Figure 45. The translation of conditional output statement is very similar to 
the translations of the previous two types of control constraints. The main difference 
is that the output condition is not optional. 

Conditional output statements are translated into Ada if-then statements, 
also. A list of output data streams may be specified in the statement and the 
translator will generate a data stream PUT procedure call for each stream in the list. 
The semantic restrictions on the conditional output statement are that no data stream 
be listed in more than one output statement; and no PSDL_EXCEPTTON data 
streams may be listed in the output statement. Output to a PSDL_EXCEPT10N data 
stream is accomplished in the EXCEPTION statement previously described. 

Control constraints are translated in the order which they are written in the 
PSDL program. The PSDL grammar does not specify a standard ordering for control 
constraints so they may be placed in any order desired as long as they all follow the 
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operator TRIGGER statement. The designer should be aware of control constraint 
ordering when using the EXCEPTION control constraint because if the EXCEPTION 
statement is executed, none of the following control constraints will be executed. All 
of the control constraint translations are combined into a single Kodiyak string and 
placed into a map in the atomic operator’s node in the abstract syntax tree. This map 
entry is then used to fill the control constraints slot in the implementation template. 



SDL: 

EXCEPTION excp ON Data_Stream IF Condition 



Ada Translation: 

if Condition_Translation then 

DSData_Stream.PUT(psdl_excp); 

return; 
end if; 



Figure 44. PSDL EXCEPTION Statement Translation 



/. Unconditional Output Slot 

Slot six in the implementation template is the unconditional output slot. 
The translator fills this slot with zero or more data stream PUT procedure calls. An 
implicit translation is made to fill the slot based on the conditional output control con- 
straints. An atomic PSDL operator must write calculated d.^.ta values to all of its out- 
put data streams sometime before it terminates. Output may be done conditionally 
using the conditional output statement described previously, or unconditionally. Any 
output data stream that is not written to in a conditional output statement must be 
written to in an unconditional output statement. 
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PSDL: 

OUTPUT X, y IF Condition 



Ada Translation: 

if Condition_Translation then 
DSx.PUT(TL_x); 
DSy.PUT(TL_y); 

end if; 



Figure 45. Conditional Output Statement Translation 



Figure 46 shows an atomic operator named AO with output data streams 
named x, y, and z. Assume that in AO’s control constraints there is a single condi- 
tional output statement in which data stream x is the only stream specified. The 
translator will generate Ada code to unconditionally output to data streams y and z at 
the end of the control constraints translations. The translations appear as 

DSy.PUT(TL_y); 

DSz.PUT(TL_z); 

in the unconditional output slot in the implementation template. 
g. Exception Closure Slot 

Slot seven in the implementation template contains the exception closure 
used to capture Ada exceptions raised by the atomic operator procedure and convert 
them to PSDL exceptions. The exception closure is translated from the 
EXCEPTIONS statement in the PSDL operator specification. The purpose of the 
EXCEPTIONS statement is to list all of the Ada exceptions that may be raised in the 
atomic procedure. The translator must construct an exception closure which recogniz- 
es those Ada exceptions and converts them to PSDL exceptions. Figure 47 shows 
an example of the statements required to construct an exception closure. 

The translator requires information gathered from the EXCEPTIONS and 
OUTPUT statements in an atomic operator’s PSDL specification in order to construct 
the exception closure. When the translator scans any output data streams of type 
PSDL_EXCEPTION, it places their names into a map. When the EXCEPTIONS 
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statement is scanned, each exception name in the list is translated into an Ada excep- 
tion handler statement of the form 

when exception_name =>, 

The translator then produces the required data stream PUT procedure calls by 
recalling the names of the output PSDL_EXCEPTION data streams. The example 
translations shown in Figure 47 would be produced for an atomic operator with output 
data streams named x and y, and exceptions named excpl and excp2. 



OPERATOR AO 

OUTPUT X, y, z : INTEGER 

END 

Elsewhere in AO’s control constraints: 

OUTPUT X IF X > 0 

Figure 46. Unconditional Output Example 



An exception closure translation is always produced for every atomic oper- 
ator regardless of the presence of an EXCEPTIONS statement. If there is no 
EXCEPTIONS statement in an atomic operator, an empty exception closure is pro- 
duced. An empty closure simply re-raises any Ada exceptions that might be raised 
by the atomic procedure. The empty closure appears as 

exception 
when others => 
raise; 

which will trap any Ada exception and raise it again to be handled elsewhere. 
"Elsewhere" in this system means the dynamic scheduler. 
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PSDL: 

OUTPUT x,y : PSDL_EXCEPTION 
EXCEPTIONS excpl, excp2 



Ada Translation: 
exception 
when excpl => 

DSx.PUT (psdl_excp 1 ); 
DSy.PUT(psdl_excpl); 
when excp2 => 

DSx.PUT(psdl_excp2); 
DSy.PUT(psdl_excp2); 
when others => 
raise; 



Figure 47. Exception Closure Example 

The completed exception closure is placed into the exception closure slot 
during pass three. After the exception closure slot is filled, the translator can then 
combine all of the filled slots of the implementation template into a single Kodiyak 
string which is the atomic operator driver. The driver is placed into a map and later 
retrieved during pass four with all the other drivers that have been produced. The 
drivers are collected as a whole and placed into the atomic operator drivers slot in the 
TL package. The final TL package translation is then produced by combining all of the 
slots of the TL package template into a single Kodiyak string. The translator then 
writes that string into a file named TL.a and the string itself is the TL package. 
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VI. CONCLUSIONS 



Implementing a PSDL to Ada translator is feasible. While the translator in this 
thesis is still only a partial implementation, it has demonstrated that there is a sys- 
tematic method to translate PSDL into Ada. The template method described in this 
thesis provides a clear picture of the mapping from PSDL to Ada. It is a tool which 
can be used to analyze the syntax/semantic relations between Ada and PSDL. The 
Kodiyak translator generator is an excellent tool for expressing syntax/semantic rela- 
tions between languages. By expressing the source language, PSDL, in terms of its 
abstract syntax tree it is relatively straight-forward to map branches of the abstract 
syntax tree into the specification and implementation templates derived in this the- 
sis. Kodiyak was found to be very flexible concerning changes to the grammar. Dur- 
ing design and implementation of the translator, the PSDL grammar was changed 
slightly. Incorporating those changes was very simple using Kodiyak. Changing the 
translation produced by Kodiyak was a simple process as well. In fact, the translator 
was constmcted by incrementally programming the Kodiyak to perform a basic trans- 
lation and then modifying on top of that version to perform the next basic translation. 

Kodiyak does have some drawbacks, however, which were noticed during re- 
search in this thesis. Kodiyak is not a language which can be learned easily. To use 
it effectively requires a familiarity with the LEX and YACC tools in UNIX. This is no 
simple task for anything less than a seasoned programmer. Kodiyak is also an ex- 
tremely resource intensive tool. Compiling the Kodiyak source code in Appendix D 
takes just over seven minutes on a dedicated Sun 3/60 workstation. The output of 
Kodiyak is an object file over 230 kilobytes in size. Perhaps the most annoying prob- 
lem with Kodiyak is its lack of high level data types and operations. The map type is 
the only high level data type offered by Kodiyak and the operations that can be per- 
formed on it are few. Manipulating groups of objects in a map is cumbersome. There 
is no looping facility to allow sequencing through a group of similar objects as can be 
done in an array in Pascal or Ada. The lack of high level data types and operations 



81 



forces the programmer to exert more effort to manipulate data structures in a Kodiyak 
program. 

Further work is necessary to make the implementation of the translator complete. 
A static semantic analyzer is necessary. Its purpose would be to accept a PSDL pro- 
gram from the user interface system, perform a thorough semantics check on it, and if 
all is well, send the syntactically and semantically correct PSDL program to the trans- 
lator and dynamic scheduler. Type checking, timing constraint analysis, and name 
checking are the primary functions required. Currently, type checking is not particular- 
ly difficult, but when user-defined data types are eventually incorporated into the 
translator, type checking will become a serious task. Simple timing constraint analy- 
sis of PSDL operators should be performed before sending a PSDL program to the 
static scheduler. This process ensures that a composite operator’s period or maxi- 
mum execution time is sufficient to allow its subcomponents to fire comfortably. 
Name checking would ensure that composite operator names are not duplicated in a 
PSDL program. This is vital to the translator and static scheduler to guarantee that 
all of the procedure names generated by the translator are unique. 

The translator, itself, still requires some enhancements to be fully operational. 
PSDL allows the software designer to construct his own user-defined data types in 
PSDL. The translator in this thesis does not translate user-defined types, all efforts 
were devoted to PSDL operators only. PSDL exceptions are not complete. This the- 
sis has developed a conceptual design for PSDL exceptions and their semantics, how- 
ever they are not implemented in the translator. Enhancements can also be made to 
improve the visibility of PSDL timers, data streams, and operators. The present im- 
plementation depends on all names of these constructs being unique throughout a 
PSDL program. Ideally, name visibility should conform to hierarchical visibility rules. 

CAPS is dependent upon an extended compiler technique for executing PSDL pro- 
grams. This technique is a two-part process. A PSDL program’s functional behavior 
is converted to machine code via translation to an underlying conventional language 
such as Ada. The PSDL program’s temporal behavior is converted to machine code 
via a scheduling algorithm which is also implemented in a conventional language. 
These two programs are then compiled and executed together to achieve the 
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real-time characteristics desired in PSDL. The research in this thesis shows that the 
translation part of the extended compiler technique is feasible and nearly complete. 
When the translator is combined with the results of research on the static and dynam- 
ic schedulers, the execution support system of the CAPS will become complete and 
automated computer aided prototyping will be significantly propelled toward reality. 
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APPENDIX A. ADA IMPLEMENTATIONS OF PSDL 

CONSTRUCTS 



A. GENERIC SAMPLED DATA STREAM PACKAGE 

with PSDL.SYSTEM; 

generic 

type ELEMENT_TTPE is private; 

package SAMPLED_STREAM is 
task DATA_STREAM is 
pragma PRIORITY (5); 

entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE : out ELEMENT_TYPE); 
entry PUT (VALUE : in ELEMENT_TYPE); 
end DATA_STREAM; 
function FRESH return BOOLEAN; 
end SAMPLED_STREAM; 

package body SAMPLED_STREAM is 

type DATA_STREAM_TOKEN is 
record 

INITIALIZED, 

NEW_DATA : BOOLEAN := false; 

VALUE : ELEMENT_TYPE; 
end record; 

task body DATA_STREAM is 

BUFFER ; DATA_STREAM_TOKEN; 

begin 

loop 

select 

accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA ;= BUFFER.NEW_DATA; 

end CHECK; 
or 
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accept GET (VALUE : out ELEMENT_TYPE) do 
if not BUFFER.INITIALIZED then 

raise PSDL_SYSTEM.BUFFER_UNDERFLOW; 
else 

VALUE := BUFFER.N_VALUE; 
BUFFER.NEW_DATA := false; 
end if; 
end GET; 



accept PUT (IN VALUE : in ELEMENT.TYPE) do 
BUFFER .VALUE := INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INITIALIZED := true; 
end PUT; 



or 

terminate; 

end select; 
end loop; 

end DATA_STREAM; 

function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 
begin 

CHECK(RESULT); 
return RESULT; 
end FRESH; 

end SAMPLED_STREAM; 



B. GENERIC DATA FLOW DATA STREAM PACKAGE 



with PSDL_SYSTEM; 
generic 

type ELEMENT_TYPE is private; 
package DATAFLOW_STREAM is 
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task DATA_STREAM is 
pragma PRIORITY (5); 

entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE : out ELEMENT_TYPE); 
entry PUT (VALUE : in ELEMENT_TYPE); 

end DATA.STREAM; 

function FRESH return BOOLEAN; 
end DATAFLOW_STREAM; 

package body DATAFLOW_STREAM is 

type DATA_STREAM_TOKEN is 
record 

INITIALIZED, 

NEW_DATA : BOOLEAN := false; 

VALUE : ELEMENT_TYPE; 
end record; 

task body DATA_STREAM is 

BUFFER ; DATA_STREAM_TOKEN; 

begin 

loop 

select 

accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER. NEW_DATA; 

end CHECK; 



accept GET (OUTVALUE : out ELEMENT_TYPE) do 

if not (BUFFER INTTIALIZED and BUFFER.NEW_DATA) then 
raise PSDL_SYSTEM.BUFFER_UNDERFLOW; 
else 

OUTVALUE := BUFFER.VALUE; 

BUFFER.NEW_DATA := false; 
end if; 
end GET; 



or 

accept PUT (INVALUE : in ELEMENT.TYPE) do 
ifBUFFER.NEW DATA then 
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raise PSDL_SYSTEM.BUFFER_OVERFLOW; 
else 

BUFFER.VALUE := INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INmALIZED := true; 
end if; 
end PUT; 



or 

terminate; 
end select; 
end loop; 

end DATA_STREAM; 



function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 
begin 

CHECK(RESULT); 
retum(RESULT); 
end FRESH; 

end DATAFLOW_STREAM; 



C. GENERIC SAMPLED STATE VARIABLE PACKAGE 



with PSDL_SYSTEM; 
generic 

type ELEMENT_TYPE is private; 

INIT1AL_VALUE : ELEMENT_TYPE; 

package SAMPLED_STATE_VAR is 

task DATA_STREAM is 
pragma PRIORITY (5); 

entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE : out ELEMENT_TYPE); 
entry PUT (VALUE : in ELEMENT_TYPE); 
end DATA_STREAM; 
function FRESH return BOOLEAN; 
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end SAMPLED_STATE_VAR; 



package body SAMPLED_STATE_VAR is 
type DATA_STREAM_TOKEN is 
record 

INITIALIZED, 

NEW_DATA : BOOLEAN := false; 

VALUE : ELEMENT.TYPE := DMITIAL.VALUE; 
end record; 

task body DATA_STREAM is 

BUFFER : DATA_STREAM_TOKEN; 

begin 

loop 

select 

accept CHECK (NEW_DATA ; out BOOLEAN) do 
NEW_DATA := BUFFER. NEW_DATA; 

end CHECK; 



accept GET (OUTVALUE : out ELEMENT_TYPE) do 
if not BUFFER.INITIALIZED then 

raise PSDL_SYSTEM.BUFFER_UNDERFLOW; 
else 

OUTVALUE := BUFFER. VALUE; 
BUFFER.NEW_DATA := false; 
end if; 
end GET; 



accept PUT (INVALUE : in ELEMENT_TYPE) do 
BUFFER.VALUE := INVALUE; 

BUFFER. INITIALIZED := true, 
BUFFER.NEW_DATA := true, 
end PUT; 



or 

terminate; 
end select; 
end loop; 

end DATA_STREAM; 
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function FRESH return BOOLEAN is 
RESULT ; BOOLEAN; 
begin 

CHECK(RESULT); 
return RESULT ; 
end FRESH; 

end SAMPLED_STATE_VAR; 



D. GENERIC DATA FLOW STATE VARIABLE PACKAGE 



with PSDL.SYSTEM; 
generic 

type ELEMENT_TYPE is private; 

INmAL_VALUE : ELEMENT_TYPE; 

package DATAFLOW_STATE_VAR is 

task DATA_STREAM is 
pragma PRIORITY (5); 

entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE : out ELEMENT_TYPE); 
entry PUT (VALUE : in ELEMENT_TYPE); 
end DATA_STREAM; 

function FRESH return BOOLEAN; 
end DATAFLOW_STATE_VAR; 



package body DATAFLOW_STATE_VAR is 

type DATA_STREAM_TOKEN is 
record 

INITIALIZED, 

NEW_DATA : BOOLEAN := false; 

VALUE : ELEMENT.TYPE := INTITAL.VALUE; 
end record; 

task body DATA_STREAM is 
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BUFFER : DATA_STREAM_TOKEN; 
begin 
loop 
select 

accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER.NEW_DATA; 
end CHECK; 



accept GET (OUTVALUE : out ELEMENT_TYPE) do 

if not (BUFFER.INmALIZED and BUFFER .NEW_DATA) then 
raise PSDL_SYSTEM.BUFFER_UNDERFLOW; 

else 

OUTVALUE := BUFFER.VALUE; 

BUFFER.NEW_DATA := false; 
end if; 
end GET ; 



accept PUT (INVALUE : in ELEMENT_TYPE) do 
if BUFFER.NEW_DATA then 

raise PSDL_S YSTEM.BUFFER_OVERFLOW ; 
else 

BUFFER.VALUE INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INmALIZED := true; 
end if; 
end PUT; 



or 

terminate; 
end select; 
end loop; 

end DATA.STREAM; 

function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 
begin 

CHECK(RESULT); 
retum(RESULT); 
end FRESH; 

end DATAFLOW_STATE_VAR; 
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E. GENERIC TIMER PACKAGE 



with PSDL_SYSTEM; 
package PSDL_TIMER is 

subtype MILLISEC is new PSDL.SYSTEM.TIMER; 

procedure RESET ; 

procedure START ; 

procedure STOP ; 

function READ return MILLISEC; 

end PSDL_T1MER; 



with CALENDAR; 

use CALENDAR; 

package body PSDL_TTMER is 



type STATE is (INITIAL, RUNNING, STOPPED); 
type TIMER is 
record 

START_TIME, 

STOP_TIME : CALENDAR.TIME; 
ELAPSED_T1ME : DURATION; 
PRESENT_STATE : STATE; 
end record; 



WATCH : TIMER; 



function READ return MILLISEC is 

CONVERSION_FACTOR : constant DURATION := 1000.0; - Converts to 
begin * — mUliseconds 

case PRESENT_STATE is 

when RUNNING => return MILLISEC((CLOCK 

- WATCH.START_miE 
+ WATCH.ELAPSED_TIME) 

* CONVERSION.FACTOR); 

when others => return MILLISEC(WATCH.ELAPSED_TIME); 
end case; 
end READ; 
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procedure RESET is 



begin 

case WATCH.PRESENT_STATE is 
when STOPPED => WATCH.ELAPSED_TIME := 0.0; 

WATCH.PRESENT_STATE := INITIAL; 
when others => null; 
end case; 
end RESET; 



procedure START is 
begin 

case WATCH.PRESENT_STATE is 
when RUNNING => null; 

when others => WATCH.START_TIME := CALENDAR. CLOCK; 

WATCH.PRESENT_STATE := RUNNING; 

end case; 
end START; 



procedure STOP is 



begin 

case WATCH.PRESENT_STATE is 

when RUNNING => WATCH. ELAPSED_TIME := CALENDAR.CLOCK 
- WATCH.START_TIME 
+ WATCH.ELAPSED.TIME; 

WATCH.PRESENT_STATE := STOPPED; 

when others => null; 
end case; 
end STOP; 

end PSDL_TIMER; 
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APPENDIX B. SPECIFICATION PACKAGE TRANSLATION 

EXAMPLE 



The purpose of this example is to demonstrate the translation of a composite oper- 
ator into a set of specification packages. The PSDL rules of visibility state that data 
streams declared in a composite operator are visible to the composite operator’s sub- 
components. The difficulty to overcome in this thesis was finding a way to allow this 
sort of hierarchical visibility stmcture in a flat physical stmcture. 

This example takes a simple PSDL operator and decomposes it into its subcompo- 
nents. A data flow diagram is presented to show the hierarchical structure of a PSDL 
operator and the data streams at each operator. The PSDL representation of the data 
flow diagram is then shown. Finally, the PSDL program is translated into a set of 
specification packages which demonstrates the flat structure of the Ada representa- 
tion and how the lines of visibility can be established using the Ada with and re- 
names clauses. 

A. DATA FLOW DIAGRAM 





b 
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B. PSDL REPRESENTATION OF DATA FLOW DIAGRAM 



OPERATOR Cl 
SPECIFICATION 

STATES a : INTEGER INITIALLY 0, 
b : FLOAT INITIALLY 1.0; 

END 

IMPLEMENTATION GRAPH 

a. EXTERNAL -> C2 

b. EXTERNAL -> C2 

a. C3 -> EXTERNAL 

b. C3 -> EXTERNAL 
C.C2 -> C3 

d.C2 -> C3 

DATA STREAM c, d : INTEGER; 

CONTROL CONSTRAINTS 
OPERATOR C2 
PERIOD 200 
OPERATOR C3 
PERIOD 200 
DESCRIPTION 

I This is the root operator. It is not allowed to have any external input or output 
data streams. To get information into the system, state variables are used. Note 
that the subcomponents are composite operators also, thus they may not have 
any control constraints like triggers, outputs, timers, or exceptions. ) 

END 

OPERATOR C2 
SPECIFICATION 

INPUT a : INTEGER, 
b : FLOAT 

OUTPUT c, d : INTEGER 
END 

IMPLEMENTATION GRAPH 
a.EXTERNAL -> A1 
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b.EXTERNAL -> A2 
C.A2 -> EXTERNAL 

d. A2 -> EXTERNAL 

e. Al -> A2 



DATA STREAM e : FLOAT 

CONTROL CONSTRAINTS 
OPERATOR A1 

TRIGGERED IF a >= 0 
OPERATOR A2 

TRIGGERED BY SOME b 
OUTPUT c IF c > 0 
DESCRIPTION 

( Operator C2 is a composite operator with atomic subcomponents A1 and A2. 
Operator C3 requires visibility to all of its parent’s data streams, a, b, c, and d. ) 

END 



OPERATOR C3 
SPECIFICATION 

INPUT c, d : INTEGER 
OUTPUT a ; INTEGER, 
b : FLOAT 

END 

IMPLEMENTATION GRAPH 

c. EXTERNAL -> A3 

d. EXTERNAL -> A4 

a. A4 -> EXTERNAL 

b. A4 -> EXTERNAL 

f.A3 -> A4 

DATA STREAM f : FLOAT 



CONTROL CONSTRAINTS 
OPERATOR A3 
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TRIGGERED 
OPERATOR A4 
TRIGGERED 
DESCRIPTION 

( Operator C2 is a composite operator with atomic subcomponents A3 and A4. 
Operator C3 requires visibility to all of its parent’s data streams, a, b, c, and d. ) 

END 

OPERATOR A1 
SPECIFICATION 

INPUT a : INTEGER 
OUTPUT e : FLOAT 
END 

IMPLEMENTATION ADA A1 { The atomic operator A1 requires visibility to data 
streams a and e in C2. ) 

END 

OPERATOR A2 
SPECIFICATION 

INPUT b,e : FLOAT 
OUTPUT c, d : INTEGER 
END 

IMPLEMENTATION ADA A2 { The atomic operator A2 requires visibility to data 
streams b, c, d, and e in C2 ) 

END 

OPERATOR A3 
SPECIFICATION 

INPUT c : INTEGER 
OUTPUT f : FLOAT 
END 

IMPLEMENTATION ADA A3 (The atomic operator A3 requires visibility to data 
streams c and f in C3 ) 
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OPERATOR A4 
SPECinCATION 

INPUT d : INTEGER, 
f : FLOAT 

OUTPUT a : INTEGER 
b : FLOAT 

END 

IMPLEMENTATION ADA A4 { The atomic operator A4 requires visibility to data 
streams a, b, d, and f in C3. ) 

END 

C. ADA SPECIFICATION PACKAGES FOR OPERATORS Cl, C2, C3, Al, 
AND A3 

package C 1_SPEC is 

— This is tlie specification package for the root operator. It instantiates data 

— streams a, b, c, and d. 

package DSa is new SAMPLED_STATE_VAR(INTEGER,0); 
package DSb is new SAMPLED_STATE_VAR(FLOAT,1.0); 
package DSc is new SAMPLED_STREAM(INTEGER); 
package DSd is new SAMPLED_STREAM(FLOAT); 
end C1_SPEC; 

with C1_SPEC; 
package C2_SPEC is 

— This is the specification package for composite operator C2. It establishes a link 

— with its parent, Cl, via the statement with C1_SPEC. Visibility is required to 

— data streams a, b, c, and d. 

package DSa renames Cl_SPEC.DSa; 
package DSb renames Cl_SPEC.DSb; 
package DSc renames Cl_SPEC.DSc; 
package DSd renames Cl_SPEC.DSd; 
package DSe is new SAMPLED_STREAM(FLOAT); 
end C2.SPEC; 



97 



with C1_SPEC; 
package C3_SPEC is 

— Tliis is the specification package for operator C3. It requires visibility to data 

— streams a, b, c, and d in C1_SPEC. 

package DSa renames Cl_SPEC.DSa; 
package DSb renames Cl_SPEC.DSb; 
package DSc renames Cl_SPEC.DSc; 
package DSd renames Cl_SPEC.DSd; 
package DSf is new SAMPLED_STREAM(FLOAT); 
end C3-SPEC; 

with C2_SPEC; use C2_SPEC; 
procedure C2_A1 is 
TL_a : INTEGER; 

TL_e : FLOAT; 
begin 
loop 

if true then 

DSa.GET(TL_a); 
if TL_a >= 0 then 
Al(TL_a, TL_e); 

DSe.PUT(TL_e); 
end if; 
end if; 
exit; 

end loop; 
end C2_A1; 

with C3_SPEC; use C3_SPEC; 
procedure C3_A3 is 
TL_c ; INTEGER; 

TL_f : FLOAT; 
begin 
loop 

if true then 

DSc.GET(TL_c); 
if true then 



98 



A3(TL_c,TL_f); 

DSf.PUT(TL_f); 

end if; 
end if; 
exit; 

end loop; 
end C3_A3; 
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APPENDIX C. PSDL GRAMMAR 



The conventions used for symbology in this grammar are standard. (Curly brac- 
es) indicate item which may appear zero or more times. [ Square brackets ] indicate 
items which may appear zero or one time in a rule. Bold face items are terminal key- 
word symbols in the grammar. "Double quotes" indicate character literals in the 
grammar. The "I" vertical bar indicates a list of options from which no more than one 
item may be selected. This grammar represents the updated version of the PSDL 
grammar as of 26 Oct 1988. 



Start = psdl 

psdl = { component ) 

component = data_type I operator 

data_type = type id type_spec type_impl 

operator = operator id operator_spec operator_impl 

type_spec = specification [type_decl] (operator id operator_spec ) 
[functionality! end 

type_impl = implementation ada id " ( " text " ) " 

I implementation type_name ( operator id operator_impl ) end 

operator_spec = specification (interface) [functionality] end 

operator_impl = implementation ada id "(" text ")" 

I implementation psdl_impl 

type_decl = id_Ust type_name ("," id_list type_name) 

functionality = [keywords] [informal_desc] [formal_desc] 

psdl_impl = data_fIow_diagram [streams] [timers] [contfol_constraints] 
[informal_desc] end 
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type_naiT»e = id "[" typ>e_decl "]" 

I id 

interface = attribute [reqmts_trace] 

id_list = id r,"id} 

keywords = keywords id_list 

informal_desc = description "(" text " 

formal_desc = axioms " ( " text " ) " 

data_flow_diagram = graph ( link } 

streams = data stream type_decl 

timers = timer id_list 

attribute = generic_param 
I input 
I output 
I states 
I exceptions 
I timing_info 

generic_param = generic type_decl 

input = input type_decl 

output = output type_decl 

states = states type_decl initially expression_list 

exceptions = exceptions id_list 

timing info = [maximum execution time time] 
[minimum calling period time] 

[maximum response time time] 
reqmts_trace = by requirements id_list 
link = id id [":" time] id 

control_constraints = control constraints (constraint) 
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constraint = operator id 

[triggered [trigger] [if predicate] [reqmts_trace]] 

[period time [reqmts_trace]] 

[finish within time [reqmts_trace]] 

{ constraint_options } 

trigger = by all idjist 
I by some id_list 

constraint_options = output id_list if predicate [reqmts_trace] 
I exception id [if predicate] [reqmts_trace] 

I timer_op id [if predicate] [reqmts_trace] 

timer_op = read timer 
I reset timer 
I start timer 
I stop timer 



expression_list = expression expression} 

time = integer [unit] 

unit = ms I sec I min I hours 

expression = constant 
lid 

I type_name id "(" expression_list ")" 

predicate = relation {bool_op relation) 

relation = simple_expression 

I simple_expression rel_op simple_expression 

simple_expression = [sign] integer [unit] 

I [sign] real 
I [not] id 
I string 

I [not] "(" predicate ")" 

I [not] boolean_constant 
bool_op = and I or 

rel_op="<" I "<=" I ">" I ">=•’ I "=" I "/=" I 
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real = integer integer 

integer = digit { digit } 

boolean_constant = true I false 

numeric_constant = real I integer 

constant = numeric_constant I boolean_constant 

sign = + I - 

char = any printable character except ’’ ) " 
digit = "0 .. 9" 
letter="a.. z"l"A..Z" I 
alpha_numeric = letter I digit 
id = letter { alpha_nuineric ) 

string = (char) 

text = (char) 
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APPENDIX D. KODIYAK PROGRAM LISTING 



The following is a listing of the Kodiyak program used to generate the translator in 
this thesis. It is based upon the Kodiyak program produced by Moffitt in [Ref. 17]. 
This program is capable of producing a translator which will translate a subset of the 
PSDL grammar. The constructs not translated by this version include: 

- PSDL exceptions. 

- User-defined types. 

Idefinitions of lexical classes 



%define Digit 
%define Int 
%defme Letter 
%define Alpha 
%define Blank 
%define Char 
%define Quote 



:[0-9] 

{ Digit ) + 
[a-zA-ZJ 
({Letter) I {Digit}) 
[NtNn] 

[^{}] 

["] 



! definitions of white space 
:{Blank) + 



! definitions of compound symbols and keywords 



GTE 

LTE 

NEQV 

ARROW 

TYPE 

OPERATOR 

SPECinCATION 

END 

GENERIC 

INPUT 

OUTPUT 

STATES 




:typelTYPE 

:operatorlOPERATOR 

ispecificationlSPECIFICATION 

:endlEND 

:genericlGENERIC 

:inputlINPUT 

:outputlOUTPUT 

:stateslSTATES 



104 



INITIALLY linitiallyllNITIALLY 

EXCEPTIONS :exceptionslEXCEPTIONS 

NORMAL inormallNORMAL 

MAX_EXEC_TIME 

:maximum[ ]execution[ ]timelMAXIMUM[ ]EXECUTION[ ]TIME 
MAX_RESP_TIME 



:maximum[ ]response[ ]timelMAXIMUM[ ]RESPONSE[ ]TIME 
MIN_CALL_PERIOD 

:minimum[ ]calling[ ]periodlMINIMUM[ ]CALLING[ ]PERIOD 



MS 

SEC 

MIN 

HOURS 

BY 

KEYWORDS 

DESCRIPTION 

AXIOMS 

IMPLEMENTATION 

ADA 

GRAPH 

DATA_STREAM 

TIMER 

CONTROL 

TRIGGERED 

ALL 

SOME 

PERIOD 

FINISH 

EXCEPTION 

READ 

RESET 

START 

STOP 

IF 

NOT 

AND 

OR 

TRUE 



:mslMS 

secISEC 

minIMIN 

hoursIHOURS 

by[ ]requirementslBY[ ]REQUIREMENTS 
ikeywordsIKEYWORDS 
idescription IDES CRIPTION 
laxiomsIAXIOMS 

limpIementationllMPLEMENTATION 

ladalAdalADA 

graphlGRAPH 

data[ ]streamlDATA[ ]STREAM 
timerlTIMER 

:control[ ]constraintslCONTROL[ ]CONSTRAENTS 

ttriggeredITRIGGERED 

:by[ ]alllBY[ ]ALL 

:by[ ]somelBY[ ]SOME 

iperiodIPERIOD 

finish[ ]withinlFINISH[ ]WITHIN 
exception I EXCEPTION 
read[ ]timerlREAD[ ]TIMER 
reset[ ]timerlRESET[ ]TIMER 
start[ ]timerlSTART[ ]TIMER 
stop[ ]timerlSTOP[ ]TTMER 
ifllF 

I "not" I "NOT" 

"&" I "and" I "AND" 

"I" I ..Qj... I 

truelTRUE 
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FALSE 

ID 

STRING.LITERAL 

INTEGER_LITERAL 

REAL.LITERAL 

TEXT 



falselFALSE 
{Letter} {Alpha}* 
{Quote} {Char}* {Quote} 
{Int} 

{Int}"."{Int} 

"{’■{Char}*"}" 



! operator precedences 

! %left means group and evaluate fix>m the left 



%left OR; 

%left AND; 

%left NOT; 

%left GTE, LTE, NEQV; 

%left 



%% 

! attribute declarations for nonterminal symbols 

start { tm: string; }; 
psdl { tm: string; 

uncond_output_map:string->string; 
out_env:string->string; 
in_env:string->string; }; 
component { tm: string; 

uncond_output_map_in:string->string; 
uncond_output_map_out:string->string; 
in_env:string->string; 
out_env:string->string; }; 

data_type { tm: string; 

in_env:string->string; }; 
operator { tm: string; 

uncond_output_map_in:string->string; 
uncond_output_map_out:string->string; 
in_env:string->string; 
out_env:string->string; }; 
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type_spec { tm: string; 
in_env;string->string; ); 

type_decl_l_list { tm; string; 

in_env:string->string; ); 

type_decl { tm; string; 

in_env,out_env ;string->string; 
opid;string; 
action_code ; string; 
ucond_output; string; ); 

op_spec_0_list { tm; string; 

in_env;string->string; ); 

operator_spec { opid; string; 
ds_decl;string; 
state_decl; string; 
ucond_output; string; 
excp_decl;string; 
in_env,out_env ;string->string; } 

interface { in_env,out_env ;string->string; 
in_parm, out_parm ; string; 
ds_decl; string; 
state_decl;string; 
excp_decl; string; 
ucond_output;string; 
opid; string; ); 

attribute { ds_decl; string; 

in_env,out_env ;string->string; 
in_parm, out_parm; string; 
opid;string; 
state_decl;string; 
ucond_output; string; 
excp_decl;string; ); 

time { tm; string; ); 

unit { value; int; }; 
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id_list { tm: string; 

action_code .‘String; 
tname: string; 
opidistring; 
ucond_output: string; 
count : int; 
exp_env:int->string; 
in_en V : string->string; 
out_env:string->string; ); 

reqmts_trace { tm: string; }; 
functionality { tm: string; ) ; 
keywords { tm: string; ); 
informal_desc { tm: string; }; 
formal_desc { tm: string; }; 
type_impl { tm: string; ); 
op_impl_0_list { tm: string; }; 
operator_impl { tm: string; 

out_env:string->string; 
in_env : string->string; 
uncond_output_map:string->string; 
loc_ds_decl:string; 
timer_decl : string; 
opid.string; ); 
psdl_impl { tm: string; 
parent : string; 

uncond_output_map:string->string; 
in_env:string->string; 
out_env:string->string; 
loc_d s_decl : string ; 
timer_decl:string; }; 

data_flow_diagram { tm: string; 

in_env, decl_map : string-> string; }; 

link_0_list { tm: string; 

in_env,in_decls,out_decls : string->string; }; 
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link { tm: string; 

in_env,in_decls,out_decls : string->string; }; 

opt_time { tm: string; ); 
type_name { tm: string; }; 
timers { tm: string; }; 
controLconstraints { tm: string; 

parent : string; 

uncond_output_map : string->string; 
in_env:string->string; 
out_env:string->string; 
decLmap : string->string; 

}; 

constraint_options { tm : string; 

in_env: string->string; 
out_env:string->string; 
opid: string; 

); 

more_constraints {tm : string; 
parent:string; 

uncond_output_map:string->string; 
in_env : string->string; 
out_env : string->string; 
decl_map : string->string; 

}; 

opt_trig { out_env:string->string; 
in_env: string->string; 
streams_check: string; 
end_if_streams: string; 
pred: string; 
end_if_pred: string; 



trigger {if: string; 
end_if:string; 

in_env, out_env:string->string; ); 
opt_per { tm: string; ); 
opt_fm_w { tm: string; ); 



109 



streams {tm: string; 

in_env,out_env :string->string; ); 
timer_op { tm: string; ); 
opt_if_predicate { if: string; 
end_if:string; 
paient:stiing; 

in_env : string-> string; ); 
predicate { tm: string; 

in_env: string->string; 
type: string; ); 
expression_list { tm: string; 
count:int; 

exp_env:int->string; ); 
expression { tm: string; ); 
relation {tm: string; 

in_env: string->string; 
type: string; }; 

simple_expression { tm: string; 
parent: string; 
in_env: string->string; 
type:string; }; 
rel_op (tm: string; 
left_op: string; 
right_op: string; 
opn_type: string; 
parent: string; ); 
sign {tm: string; ); 

lattrbute declarations for terminal symbols 

ID{ %text: string; ); 

TEXT{ %text: string; ); 
STRING_LITERAL{ %text: string; ); 
INTEGER_LITERAL{ %text: string; ); 
REAL_LITERAL {%text: string; ); 

%% 

Ipsdl grammar 



no 



start 



: psdl 

{ %output(["with PSDL_SYSTEM;\nuse PSDL_SYSTEM;\npackage TL isVi", 
psdl.tm,"end TL;\n"]); 
psdl.in_env = psdl.out_env; 

} 



psdl 

: component psdl 

{ psdl[l].tm = [component.tm,"\n",psdl[2].tm]; 

psdl[l].out_env = component.out_env +1 psdl[2].out_env; 
psdl[l].uncond_output_map = component.uncond_output_map_out 
+1 psdl[2].uncond_output_map; 
component. in_env = psdl[l].in_env; 

component.uncond_output_map_in = psdl[2].uncond_output_map; 
psdl[2].in_env = psdl[l].in_env ; 

} 

I 

{ psdl.tm = 

psdl.out_env = {(?:string:"")}; 
psdl.uncond_output_map = {(?:string:"")} ; 

} 



component 
: data_type 
{ component.tm = 

component.out_env = {(?:string:"")}; 

component. uncond_output_map_out = {(?:string:"")}; 

data_type.in_env = component.in_env; 

} 

I operator 

{ component.tm = operator. tm; 

component.out_env = operator.out_env; 

component. uncond_output_map_out = operator.uncond_output_map_out; 
operator.in_env = component.in_env; 
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operator. uncond_output_map_in = component.uncond_output_map_in; 

) 



data_type 

; TYPE ID type_spec type_impl 
{ data_type.tm = 

type_spec.in_env = data_type.in_env; 

) 



operator 

: OPERATOR ID operator_spec operator_impl 
{ operator, tm = 

(operator.in_env(ID.%text^"CONSTRUCT") == "composite_operator" 
-> ["\npackage ", 

ID.%text,"_SPEC is\n",operator_spec.ds_decl,’'\n", 
operator_impl.loc_ds_decl, "\n " , 
operator_spec. state_decl, "\n " , 
operator_impl. timer_decl , "\n " , 
operator_spec.excp_decl,"\nend ", 
ID.%text,"_SPEC;\n",operator_impl.tm] 

# "" 

); 

operator. uncond_output_map_out = 

{ (ID.%text:operator_spec.ucond_output) } ; 



operator_spec.opid = ID.%text; 
operator_spec.in_env = operator.in_env; 
operator_impl.opid = ID.%text; 

operator_impl.in_env = {("PARENT":ID.%text)} +1 operator.in_env; 
operator_impl.uncond_output_map = operator.uncond_output_map_in; 
operator.out_env = operator_spec.out_env +1 operator_impl.out_env; 

} 



type_spec 

: SPECIFICATION type_decl_l_list op_spec_0_list functionality END 
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{ iype_spec.tm = 

type_decl_l_Iist.in_env = type_spec.in_env; 
op_spec_0_list.in_env = type_spec.in_env; 

) 



type_decl_l_list 
: type_decl 

{ type_decl_l_list.tm = type_decl.tm; 
type_decl.action_code = "type"; 
type_decl.in_env = type_decl_l_list.in_env; 



} 



{type_decl_l_list.tm = 



type_decl 

: id_list type_name 
{ type_decl.tm = id_list.tm; 

type_decl.out_env = id_list.out_env; 
type_decl.ucond_output = id_list.ucond_output; 
id_list.in_env = type_decl.in_env; 
id_list.action_code = type_decl.action_code; 
id_list.tname = type_name.tm; 
id_list.opid = type_decl.opid; 
id_list.count = 1,; 
id_list.exp_env = {(?:int:"")}; 

} 

I id_list type_name type_decl 
{ type_decl[l].tm = id_lisLtm ^ type_decl[2].tm; 
type_decl[l].out_env = id_list.out_env +1 type_decl[2].out_env 
type_decl.ucond_output = id_list.ucond_output 
^ type_decl[2].ucond_output; 

id_list.in_env = type_decl[l].in_env; 
id_list.action_code = type_decl[l].action_code; 
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id_list.tname = type_name.tm; 

id_list.opid = type_decl[l].opid; 

id_list. count = 1; 

id_list.exp_env = {(?:int:"")); 

type_decl[2].in_env = type_decl[l].in_env; 

type_decl[2].opid = type_decl[l].opid; 

type_decl[2].action_code = type_decl[l].action_code; 

) 

op_spec_0_list 

: op_spec_0_list OPERATOR ID operator_spec 
{ op_spec_0_list[l].tm = 

operator_spec.in_env = op_spec_0_list.in_env; 
op_spec_0_list[2].in_env = op_spec_0_list[l].in_env; 

} 

I 

{ op_spec_0_list.tm = } 



operator_spec 

: SPECIFICATION interface functionality END 
{ operator_spec.ds_decl = interface.ds_decl; 
operator_spec.state_decl = interface.state_decl; 
operator_spec.excp_decl = interface.excp_decl; 
operator_spec.ucond_output = interface.ucond_output; 
operator_spec.out_env = 

(interface.out_env(operator_spec.opid'^"INPARM") == "" II 
interface.out_env(operator_spec.opid'^"OUTPARM") == "" 
-> { ((operator_spec.opid^"PROCCALL"): 

[interface.out_env(operator_spec.opid^"INPARM"), 
interface.out_env(operator_spec.opid^"OUTPARM")])) 
# { ((operator_spec.opid'^"PROCCALL"): 
[interface.out_env(operator_spec.opid'^"INPARM"),",", 
interface.out_env(operator_spec.opid'^"OUTPARM")])) 
) +1 interface.out_env; 

interface.in_env = operator_spec.in_env; 
interface.opid = opera tor_spec.opid; 
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} 



interface 

: interface attribute reqmts_trace 
{ interface[l].ds_decl = 

[interface[2].ds_decl,"\n",attribute.ds_decl]; 
interface[l].state_decl = 

[in terface[2] . state_decl ,"\n ", attribute. state_decl] ; 
interface[l].excp_decl = 

[i nterface[2] .excp_decl ,’’\n " ,attribute.excp_decl] ; 
interface[l].in_parm = interface[2].in_parm ^ attribute.in_parm; 
interface[l].out_parm = interface[2].out_parm ^ attribute.out_parm; 

interface[l].out_env = 

{((interface[l].opid^"INPARM"):interface[l].in_parm) 
((interface[l].opid''"OUTPARM"):interface[l].out_parm) ) 

+1 interface[2].out_env +1 attribute.out_env; 

interface[l].ucond_output = interface[2].ucond_output 
^ attribute.ucond_output; 

interface[2].opid = interface[l].opid; 
interface[2].in_env = interface[l].in_env; 
attribute.in_env = interface[l].in_env; 
attribute.opid = interface[l].opid; 

} 



(interface.ds_decl = 
interface.state_decl = 
interface.excp_decl = 
interface.in_parm = 
interface.out_parm = 
interface.out_env = {(?:string:"")}; 
interface.ucond_output = 

} 
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attribute 

: GENERIC type_decl 

{ type_decl.action_code = 
type_decl.opid = attribute.opid; 
type_decl.in_env = attribute.in_env; 
attribute.out_env = type_decl.out_env; 
attribute.ds_decl = 
attribute.state_decl = 
attribute.excp_decl = 
attribute.in_parm = 
attribute.out_parm = 
attribute.ucond_output = 

} 

I INPUT type_decl 

{ type_decl.action_code = "input"; 
type_decl.opid = attribute.opid; 
type_decl.in_env = attribute.in_env; 
attribute .out_env = type_decl.out_env; 
attribute .ds_decl = type_decl.tm; 
attribute. state_decl = ""; 
attribute.excp_decl = ""; 

attribute.in_parm = type_decl.out_env(attribute.opid^"INPARM"); 
attribute.out_parm = ""; 
attribute.ucond_output = 



} 

I OUTPUT type_decl 

{ type_decl.action_code = "output"; 
type_decl.opid = attribute.opid; 
type_decl.in_env = attribute.in_env; 
attribute.out_env = type_decl.out_env; 
attribute.ds_decl = type_decl.tm; 
attribute.state_decl = ""; 
attribute.excp_decl = ""; 
attribute.in_parm = ""; 

attribute.out_parm = type_decl.out_env(attribute.opid'^"OUTPARM"); 
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attribute. ucond_output = type_decl.ucond_output; 



} 

I STATES id_list ID INITIALLY expression_list 
{ id_list.action_code = "states"; 
id_list.opid = attribute.opid; 
id_list.tname = ID.%text; 
id_list.count = 1 ; 

id_list.exp_env = expression_list.exp_env; 
id_list.in_env = attribute.in_env; 
expression_list. count = 1; 
attribute.out_env = id_list.out_env; 
attribute.ds_decl = 
attribute.state_decl = id_list.tm; 
attribute .excp_decl = 
attribute. in_parm = 
attribute.out_parm = 
attribute.ucond_output = 



} 

I EXCEPTIONS idjist 

{ id_list.action_code = "excp"; 
id_list.tname = "exception"; 
id_list.opid = attribute.opid; 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 
id_list.in_env = attribute.in_env; 
attribute.out_env = id_list.out_env; 
attribute.ds_decl = ""; 
attribute.state_decl = 

attribute.excp_decl = [id_list.tm," : PSDL_EXCEPTION;\n"]; 
attribute.in_parm = ""; 
attribute.out_parm = ""; 
attribute.ucond_output = ""; 



} 
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I MAX_EXEC_TIME time 
{ attribute.ds_decl = 
attribute.state_decl = 
attribute.excp_decl = 
attribute.out_env = {(?:string:"")}; 
attribute.in_parm - 
attribute.out_parm = 
attribute.ucond_output = 

} 

I MIN_CALL_PERIOD time 
{ attribute.ds_decl = 
attribute. state_decl = 
attribute.excp_decl = 
attribute.out_env = {(?:string:"")}; 
attribute.in_parm = 
attribute.out_parm = 
attribute.ucond_output = 



I MAX_RESP_TIME time 
{ attribute.ds_decl = 
attribute.state_decl = 
attribute.excp_decl = 
attribute.out_env = {(?:string:"")}; 
attribute.in_parm = 
attribute.out_parm = 
attribute.ucond_output = 



} 



id_list 

; ID idjist 
{ id_list[l].tm = 

(id_list[l].action_code == "input" II 
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id_list[l].action_ccxle == "output" 

-> (id_list[l].in_env(id_list[l].opid'^"PARENT") == "" 

-> ["package DS",ID.%text," is new ", 
(id_list[l].in_envaD.%text^"BUFF_TYPE") == "fifo" 

-> "FIFO.BUFFER" 

# "SAMPLED.BUFFER") 

,"(",id_list[l].tname,");\n"] 

# ["package DS",ID.%text," renames ", 
id_list[l].in_env(id_list[l].opid^"PARENT"),"_SPEC.DS", 
ID.%text,";\n"]) ^ id_list[2].tm 

# id_list[l].action_code == "states" 

-> ["package DS",ID.%text," is new STATE_VARIABLE(", 
id_list[ 1 ] . tname, ", " ,id_list[ 1 ] .exp_env(id_list[ 1 ] .count), 

");\n"] ^ id_list[2].tm 

# id_list[l].action_code == "excp" 

-> ["EX",ID.%text,",",id_list[2].tm] 

# id_list[l].action_code == "stream" 

-> ["package DS",ID.%text," is new ", 

(id_list[l].in_env(ID.%text''"BUFF_TYPE") == "fifo" 

-> "FIFO.BUFFER" 

# "SAMPLED_BUFFER"), "(",id_list[l].tname,");\n"] 

^ id_list[2].tm 

# id_list[l].action_code == "timer" 

-> ["TL",ID.%text,",",id_list[2].tm] 



# id_list[l].action_code == "by_all" 

-> [id_list[l].opid,"_SPEC.DS",ID.%text,".NEW_DATA"," AND \n", 
id_list[2].tm] 

# id_list[l].action_code == "by_some" 

-> [id_list[l].opid,"_SPEC.DS",ID.%text,".NEW_DATA"," OR \n", 
id_list[2].tm] 

# id_list[l].action_code == "co_output" 
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->[id_list[l].in_env(id_list[l].opid'^"PARENT"),’’_SPEC.DS", 

ID.%text,".WRITE(MD.%text,");\n",idJist[2].tm] 



# 

id_list[2].in_env = id_list[l].in_env; 

id_list[2].action_code = id_list[l].action_code; 

id_list[2].opid = id_list[l].opid; 

id_list[2].tname = id_list[l].tname; 

id_list[2].exp_env = id_list[l].exp_env; 

id_list[2] .count = id_list[l].exp_env(id_list[l]. count + 1) <> "" 

-> id_list[l]. count + 1 
# id_list[l]. count; 

id_list[l].out_env = 

(id_list[l].action_code == "by_all" 

-> {((ID.%text^"BUFF_TYPE"):"fifo’’)} +1 id_list[2].out_env 

# id_list[l].action_code == "by_some" 

-> {((ID.%text^"BUFF_TYPE"):"sampled")} +1 id_list[2].out_env 

# id_list[l].action_code == "input" 

-> {((ID.%text'^"TYPE"):id_list[l].tname) 
(aD.%text'^"CONSTRUCT"):"data_stream") 
((id_list[l].opid'^"INPARM");[ID.%text,",", 
id_list[2].out_env(id_list[2].opid'^"INPARM")]) 

) +1 id_list[2].out_env 

# id_list[l].action_code == "output" 

-> {((ID.%text^’TYPE"):idJist[l].tname) 
((ID.%text^"CONSTRUCT"):"data_stream") 
((id_list[l].opid^"OUTPARM"):[ID.%text,",", 
id_Ust[2].out_env(id_list[2].opid^"OUTPARM")]) 

} +1 id_list[2].out_env 

# id_list[l].action_code == "stream" 

-> {((ID.%text^"TYPE"):id_list[l].tname) 
(aD.%text^"CONSTRUCT"):"data_stream")} +1 id_list[2].out_env 
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# id_list[l].action_code == "states" 

-> {((ID.%text^"TYPE"):id_list[l].tname) 

(aD.%text^"CONSTRUCT"):"data_stream")} +1 id_list[2].out_env 

# id_list[l].action_code == "excp" 

-> {((ID.%text'^"CONSTRUCT"):"exception")} +1 id_list[2].out_env 

# id_list[l].action_code == "timer" 

-> {((ID.%text^"CONSTRUCT"):"timer")} +1 id_list[2].out_env 

# id_list[l].action_code == "co_output" 

-> {([id_Ust[l].opid,"_",ID.%text,"OUTPUT"]:"conditional")} 

+1 id_list[2].out_env 

# {(?:string:"")} 

); 



id_list.ucond_output = 

((id_list[l].in_env(id_list[l].opid'^"_"'^ID.%text'^"OUTPUT") 

<> "conditional" ) && 

(id_list[l].action_code == "output") 

-> [idJist[l].in_env(id_list[l].opid'^"PARENT"),"_SPEC.DS", 
ID.%text,".WRITE(",ID.%text,");\n"] 

# "" 

) ^ id_list[2].ucond_output; 



} 



I ID 



{ id_list.tm = 

(id_list.action_code == "input" II 
id_list.action_code == "output" 

-> (id_list.in_env(id_list.opid^"PARENT") = "" 

-> ["package DS",ID.%text," is new ", 
(id_list.in_env(ID.%text^"BUFF_TYPE") == "fifo" 



-> "FIFO.BUFFER" 

# "SAMPLED.BUFFER") 
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,"("»id_lisLtname,");\n"] 

# [’’package DS",ID.%text," renames ", 
id_list.in_env(id_list.opid^’’PARENT’’),’’_SPEC.DS’’, 
ID.%text,’’;\n’’]) 

# id_list.action_code == "states" 

-> [’’package DS’’,ID.%text," is new STATE_VARIABLE(", 
id_list.tname,’’, ",id_list.exp_env(id_list.count), 

");\n"] 

# id_list.action_code = "excp" 

-> [’’EX’’,ID.%text] 

# id_list.action_code == "stream" 

-> [’’package DS",ID.%text,’’ is new ", 

(id_list.in_envaD.%text^’’BUFF_TYPE") == "fifo" 

-> "FIFO_BUFFER" 

# "SAMPLED_BUFFER"), ’’(’’,id_Ust.tname,");\n’’] 

# id_list.action_code == "timer" 

-> [’’TL’’,ID.%text] 

# id_list.action_code == "by_aH" 

-> [id_list.opid,’’_SPEC.DS’’,ID.%text,".NEW_DATA"] 

# id_list.action_code == ’’by_some" 

-> [id_list.opid,’’_SPEC.DS",ID.%text,’’.NEW_DATA"] 

# id_list.action_code == ’’co_output" 

-> [id_list.in_env(id_list.opid^’’PARENT’’),’’_SPEC.DS’’,ID.%text, 
’’.WRITE(",ID.%text,’’);\n’’] 



id_list.out_env = 

(id_list.action_code == "by_aH’’ 

-> (((ID.%text^’’BUFF_TYPE’’):’’fifo’’)} 

# id_list.action_code == ’’by_some" 
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-> {((ID.%texl^"BUFF_TYPE"):’’sampled")} 



# id_list[l].action_code == "input" 

-> {((ID.%text^"TYPE"):id_list[l].tname) 
((ID.%text^"CONSTRUCT"):"data_stream") 
((id_list.opid^"INPARM"):ID.%text)} 

# id_list[l].action_code == "output" 

-> { ((ID.%text^"TYPE"):id_list[ 1 ] .tname) 
((ID.%text^"CONSTRUCT"):"data_stream") 
((id_list.opid^"OUTPARM"):ID.%text)} 

# id_list[l].action_code == "stream" 

-> {((ID.%text^"TYPE"):idJist[l].mame) 
((ID.%text^"CONSTRUCT"):"data_stream")) 

# id_list[l].action_code == "states" 

-> { ((ID!%text^"TYPE"):id_list[ 1 ] .tname) 
(aD.%text^"CONSTRUCT"):"data_stream")} 

# id_list.action_code == "excp" 

-> {((ID.%text^"CONSTRUCT"):"exception")) 

# id_list.action_code == "timer" 

-> { ((ID.%text^"CONSTRUCT"):"timer") ) 

# id_list.action_code == "co_output" 

-> {([id_Ust.opid,"_",ID.%text,"OUTPUT"]:"conditional")} 

# {(?:string:"")} 

); 



id_list.ucond_output = 

((id_list.in_env(id_list.opid'^"_"^ID.%text'^"OUTPUT")o"conditional") 
&& (id_list.action_code == "output") 

-> [id_list.in_env(id_Ust.opid^"PARENT"),"_SPEC.DS",ID.%text, 

".WRITECMD.%text,");Nn"] 

# "" 

); 
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} 



time 

: INTEGER_LrTERAL unit 
{ time.tm = } 



unit 
: MS 

{ unit. value = 1; 

} 

I SEC 

{ unit. value = 1000; 

} 

I MIN 

{ unit.value = 60000; 

} 

I HOURS 

{ unit.value = 3600000; 

} 



reqmts_trace 
: BY idjist 
{ reqmts_trace.tm = 

id_list.in_env = {(?:string:"")}; 
id_list.action_code = 
id_list.tname = 
id_list.opid = 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 

} 
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{ reqmts_trace.tm = ) 

y 

functionality 

: keywords informal_desc fonnal_desc 
{ functionality. tm = } 

y 

keywords 

: KEYWORDS idjist 
{ keywords. tm = 

id_list.in_env = {(?: string 
id_list.action_code = 
id_list.tname = 
id_list.opid = 
id_list.count = 1 ; 
id_list.exp_env = {(?:int:"")}; 

} 

I 

{ keywords.tm = } 

y 

informal_desc 
: DESCRIPTION TEXT 
{ informal_desc.tm = "\n"; ) 

I 

{informal_desc.tm = } 

y 

formal_desc 
: AXIOMS TEXT 
{ formal_desc.tm = "\n"; } 

I 

{ formal_desc.tm = } 

y 

type_impl 
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: IMPLEMENTATION ADA ID 
{ type_impl.tm = ["procedure ",ID.%text," is;\n"]; } 

I IMPLEMENTATION type_name op_impl_0_list END 
{ type_impl.tm = ["\n package DATA_TYPES is\n",type_name.tm,"\n", 
op_impl_0_list.tm,"\n ", 

"end;\n"]; ) 



op_impl_0_list 

: op_impl_0_list OPERATOR ID operator_impl 
{ op_impl_0_list[l].tm = 

operator_impl.opid = ID.%text; } 

I 

{ op_impl_0_list[l].tm = ""; } 



operator_impl 

: IMPLEMENTATION ADA ID 
{ operator_impl.tm = 

operator_impUoc_ds_decl = 
operator_impl,timer_decl = 

operator_impl.out_env = { ((ID.%text^"CONSTRUCT"):"atomic_operator")} ; 

} 

\ IMPLEMENTATION psdljmpl 
{ operator_impl.tm = psdl_impl.tm; 

operator_impl.loc_ds_decl = psdl_impUoc_ds_decl; 
operator_impl.timer_decl = psdl_impl.timer_decl; 
psdl_impl.parent = operator_impl.opid; 
psdl_impl.in_env = operator_impl.in_env; 

psdl_impl.uncond_output_map = operator_impl.uncond_output_map; 
operator_impl.out_env = 

{ ((operator_impl.opid^"CONSTRUCT"):"composite_operator") } +1 
psdl_impl.out_env; 

} 



psdl_impl 
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: data_flow_diagram streams timers control_constraints informal_desc END 
{ psdl_impl.tm = control_constraints.tm; 

psdl_impl.out_env = streams.out_env +1 control_constraints.out_env; 

psdl_impLloc_ds_decl = streams.tm; 

psdl_impl.timer_decl = timers.tm; 

data_flow_diagram.in_env = psdl_impl.in_env; 

streams.in_env = psdl_impl.in_env; 

controLconstraints.parent = psdl_impl.parent; 

control_constraints.in_env = psdl_impl.in_env; 

control_constraints.decl_map = data_flow_diagram.decl_map; 

control_constraints.uncond_output_map = psdl_impl.uncond_output_map; 

} 



data_flow_diagram 
: GRAPH link_0_list 
( data_flow_diagram.tm = 

data_flow_diagram.decl_map = link_0_list.out_decls; 
link_0_list.in_decls = {(?:string:"")}; 
link_0_list.in_env = data_flow_diagram.in_env; 

} 



link_0_list 
: link link_0_list 
{ link_0_list[l].tm = 

Iink_0_list[l].out_decls = link_0_list[2].out_decls; 
link_0_list[2].in_decls = link.out_decls; 
link.in_decls = Iink_0_list[l].in_decls; 
link.in_env = link_0_list[l].in_env; 
link_0_list[2].in_env = link_0_list[l].in_env; 

} 

I 

{ Unk_0_lisLtm = 

link_0_list.out_decls = link_0_list.in_decls; 

} 
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link 

: ID ID opt_time ARROW ID 
{ link.tm = 

link.out_decls = 

(link.in_decls(ID[3].%text^ID[I].%text^"READ") = "dup" 

-> {(?:string:'"')) 

# {((ID[3].%text^"READ"):[link.in_decls(ID[3].%text^"READ’’), 

link.in_envrPARENT"),"_SPEC.DSMD[l].%text;'.READ(MD[l].%text, 
");\n"]) ((ID[3].%text^ID[l].%text^"READ"):’’dup")} 

)+l 

(link.in_decls([ID[2].%text;’_MD[l].%text]) == "dup" 

-> {(?:string:"")} 

# { aD[2].%text:[link.in_declsaD[2].%text), 

ID[I].%text," : ",link.in_env(ID[l].%text'^"TYPE"), 

";\n"]) ([ID[2].%text,"_MD[I].%text]:"dup")} 

)+l 

(link.in_decls([ID[3].%text,"_",ID[l].%text]) == "dup" 

-> {(?:string:"")} 

# {(ID[3].%text:[link.in_decls(ID[3].%text), 

ID[l].%text," : ’Mink.in_envaD[l].%text^"TYPE"), 

";\n"]) ([ID[3].%text,"_",ID[l].%text];"dup")} 

) +1 link.in_decls; 

} 



opt_time 
: time 

{ opt_time.tm = ""; } 

I 

{ opt_time.tm = "\n"; } 



streams 

: DATA_STREAM type_decl 
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{ streams.tm = type_decl.tm; 

streams.out_env = type_decl.out_env; 
type_decl.opid = 

type_decl.action_code = "stream"; 
type_decl.in_env = streams.in_env; 

} 

I 

{streams.tm = 

streams.out_env = ((?: string:"")); 

) 



type_name 
: ID ’[’ type_decl ’]’ 

( type_name.tm = [ID.%text,"[",type_decl.tm,"]\n"]; 
type_decl.opid = ""; 
type_decl.action_code = "mame"; } 

IID 

( type_name.tm = ID.%text; } 



timers 

: TIMER id_list 

{ timers.tm = [id_list.tm," : PSDL_TIMER;\n"]; 
id_list.in_env = ((?:string:"")}; 
id_list.action_code = "timer"; 
id_list.mame = ""; 
id_list.opid = ""; 
id_list.count = 1; 
id_list.exp_env = ((?:int:"")); 

} 



(timers.tm = 

) 



controLconstraints 
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: CONTROL 

{ controLconstraints.tm = 

control_constraints.out_env = {(?:string:"")}; 

} 

I CONTROL OPERATOR ID opt_trig opt_per opt_fin_w consiraint_options 
more_constraints 
{controLconstraints.tm = 

(control_constraints.in_env(ID.%text^"CONSTRUCT") 

= "composite_operator" 

-> ["procedure ",control_constraints.in_env("PARENT"),"_"» 
ID.%text," is\n beginXn nuU;\n end ", 
control_constraints.in_env("PARENT"),"_",ID.%text,";\n"] 

# ["procedure ",control_constraints.in_env("PARENT"), 
"_",ID.%text," is\n",control_constraints.decl_map(ID.%text), 
''\nbegin\n",opt_trig.streams_check, 
control_constraints.decl_map(ID.%text'^"READ"), 
opt_trig.pred, 

(control_constraints.in_env(ID.%text^"PROCCALL") == "" 

-> [ID.%text,";\n"] 

# [ID.%text,T, 

control_constraints.in_env(ID.%text^"PROCCALL") ,");\n"] 

), 

constraint_options. tm, "\n " , 

control_constraints.uncond_output_map(ID.%text), 

opt_trig.end_if_pred,opt_trig.end_if_streams, 

"end ",control_constraints.in_env("PARENT"), 

"_",ID.%text,";\n"] 

) ^ more_constraints.tm; 

opt_trig.in_env = control_constraints.in_env; 
constraint_options.in_env = control_constraints.in_env; 
constraint_options.opid = ID.%text; 
control_constraints.out_env = 

{ ((ID.%text^"PARENT"):control_constraints.parent) } 

+1 opt_trig.out_env 
+1 constraint_options.out_env 
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+1 more_constraints.out_env; 

more_constraints.parent = control_constraints.parent; 
more_constraints.in_env = control_constraints.in_env; 
more_constramts.uncond_output_map = 
control_constraints.uncond_output_map; 
more_constraints.decl_map = control_constraints.decl_map; 
} 



{controLconstraints.tm = 
control_constraints.out_env = {(?:string:"")}; 
} 



more_constraints 

: OPERATOR ID opt_trig opt_per opt_fin_w constraint_options 
more_constraints 
{ more_constraints[ 1 ] .tm = 

(more_constraints.in_env(ID.%text'^"CONSTRUCT") == 
"composite_operator" 

-> ["procedure ",more_constraints[l].in_env("PARENT"),"_", 
ID,%text," is\n beginNn null;\n end ", 
more_constraints[l].in_env("PARENT"),"_",ID.%text,";\n"] 

# ["procedure ",more_constraints[l].in_env("PAREN^"), 
"_",ID.%text," isNn",more_constraints[l].decl_mapv- J.%text), 
"\nbegin\n " ,opt_trig. streams_check, 
more_constraints.decl_map(ID.%text''"READ"), 
opt_trig.pred, 

(more_constraints[l].in_env(ID.%text''"PROCCALL") == "" 

-> [ID.%text,";\n"] 

# [ID.%text,"(", 

more_constraints[ 1 ] .in_env(ID.%text''"PROCCALL"),");\n"] 

), 

constraint_options.tm,"\n", 

niore_constraints[l].uncond_output_map(ID.%text), 

opt_trig.end_if_pred,opt_trig.end_if_streams, 
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"end ",more_constraints[l].in_env("PARENT"), 

) ^ more_constraints[2].tm; 

opt_trig.in_env = more_constraints.in_env; 
constraint_options.in_env = more_constraints.in_env; 
constraint_options.opid = ID.%text; 
more_constraints[l].out_env = 

{ ((ID.%text'^"PARENT"):more_constraints.parent)) +1 
opt_trig.out_env +1 
constraint_options.out_env +1 
more_constraints[2] .out_env; 
more_constraints[2].in_env = more_constraints[l].in_env; 
more_constraints[2].uncond_output_map = 
more_constraints[ 1 ].uncond_output_map; 
more_constraints[2].decl_map = more_constraints[l].decl_map; 



{more_constraints.tm = 
more_constraints.out_env = {(?:string:"")} ; 
} 



constraint_options 

: OUTPUT id_list IF predicate reqmts_trace constraint_options 
{ constraint_options[l].tm = 

["if ",predicate.tm,"\nthen\n ",id_list.tm,"\nend if;\n", 
constraint_options[2].tm] ; 

constraint_options[2].opid = constraint_options[l].opid; 
constraint_options[2].in_env = constraint_options[l].in_env; 
constraint_options[l].out_env = id_list.out_env +1 

constraint_options[2] .out_env; 
predicate.in_env = constraint_options[l].in_env; 
id_list.in_env = constraint_options[l].in_env; 
id_list.action_code = "co_output"; 
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id_list.tname = 

id_list.opid = constraint_options.opid; 
id_list.count = 1 ; 
id_list.exp_env = {(?:int:"")}; 

} 

I EXCEPTION ID opt_if_predicate reqmts_trace constraint_options 
{ constraint_options[l].tm = constraint_options[2].tm; 
constraint_options[l].out_env = constraint_options[2].out_env; 
constraint_options[2].opid = constraint_options[l].opid; 
constraint_options[2].in_env = constraint_options[l].in_env; 
opt_if_predicate.in_env = constraint_options[l].in_env; 

} 

I timer_op ID opt_if_predicate reqmts_trace constraint_options 
{ constraint_options[l].tm = 

[opt_if_predicate.if,timer_op.tm,"( "» 

constraint_options[l].in_env("PARENT"),"_SPEC.TL",ID.%text, 
");Nn",opt_if_predicate.end_if,constraint_options[2].tm]; 
constraint_options[l].out_env = constraint_options[2].out_env; 
constraint_options[2].opid = constraint_options[l].opid; 
constraint_options[2].in_env = constraint_options[l].in_env; 
opt_if_predicate.in_env = constraint_options[l].in_env; 

} 



I 

{ constraint_options.tm = 
constraint_options.out_env = {(?:string:"")}; 

} 

> 



opt_trig 

: TRIGGERED trigger opt_if_predicate reqmts_trace 
{ opt_trig.out_env = trigger.out_env; 
opt_trig.pred = opt_if_predicate.if; 
opt_trig.end_if_pred = opt_if_predicate.end_if; 
opt_trig.streams_check = trigger.if; 
opt_trig.end_if_streams = trigger.end_if; 
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trigger.in_env = opt_trig.in_env; 
opt_if_predicate.in_env = opt_trig.in_env; 

} 

{opt_trig.out_env = {(?:string:"")}; 
opt_trig.pred = 
opt_trig.end_if_pred = 
opt_trig.streams_check = 
opt_trig.end_if_streams = 

} 



trigger 
: ALL id_list 

{ trigger.if = ["if ",id_list.tm,"\nthen\n"]; 
trigger.end_if = "end 
trigger.out_env = id_list.out_env; 
id_list.action_code = "by_all"; 
id_list.tname = 

id_list.opid = trigger.in_env("PARENT"); 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 

) 

I SOME idjist 

( trigger.if = ["if ",id_list.tm,’'\nthen\n"]; 
trigger.end_if = "end if;\n"; 
trigger.out_env = id_list.out_env; 
id_list.action_ccxie = "by_some"; 
id_list.tname = ""; 

id_list.opid = trigger.in_env("PARENT"); 
id_list.count = 1; 
id_list.exp_env = ((?:int:"")}; 

} 

I 

{ trigger.if =""; 
trigger.end_if = 
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trigger.out_env = {(?:siring:"")}; 

} 



opt_per 

:PERIOD time reqmts_trace 
{ opt_per.tm = "Sn"; } 

I 

{ opt_per.tm = } 



opt_fin_w 

: FINISH time reqmts_trace 
{ opt_fin_w.tm = "\n"; } 

I 

{ opt_fin_w.tm = ) 



timer_op 
: READ 

{ timer_op.tm = "PSDL_TIMER.READ"; ) 
I RESET 

{ timer_op.tm = " PS DL_TIMER. RESET"; } 

I START 

{ timer_op.tm = "PSDL.TIMER.START"; } 

I STOP 

{ timer.op.tm = "PSDL.TIMER.STOP"; ) 



opt_if_predicate 
: IF predicate 

{ opt_if_predicate.if = ["if ",predicate.tm,'*\nthen\n"]; 
opt_if_predicate.end_if = "end if;\n"; 
predicate.in_env = opt_if_predicate.in_env; 



} 
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{opt_if_predicate.if = 
opt_if_predicate.end_if = 
} 



expression_list 
; expression 

{expression_list.tm = expression, tm; 

expression_list.exp_env = {(expression_list.count;expression.tm) 
(0:i2s(expression_list.count)) 

I expression expression_list 
{expression_list[l].tm = 

[expression.im,",",expression_list[2].tm]; 
expression_list[l].exp_env = 

{ (expression_list[ 1 ] .countrexpression.tm) } +1 
expression_list[2] .exp_en v; 

expression_list[2] .count = expression_list[l]. count + 1; } 



expression 

: INTEGER_LITERAL 

{ expression. tm = INTEGER_LrTERAL.%text; } 

I REAL_LITERAL 

{ expression .tm = REAL_LITERAL.%text; } 

I STRING.LITERAL 

{ expression. tm = STRING_LITERAL.%text; } 

I TRUE 

{ expression. tm = " tme } 

I FALSE 

{expression.tm = " false } 

IID 

{expression.tm = ID.%text; } 

I type_name ID ’(’ expression_list ’)’ 

(expression.tm = [type_name.tm,ID.%text,’’( ">expression_list.tm, 



136 



’■) "]; 

expression_list.count = 1; } 

y 

predicate 

: relation 

(predicate.tm = relation.tm; 
predicate, type = relation, type; 
relation. in_env = predicate. in_env; 

} 

I relation AND predicate 

{predicate[l].tm = [relation.tm," and ",predicate[2].tm]; 
predicate[l].type = 

predicate[2].in_env = predicate[l].in_env; 
relation. in_env = predicate[l].in_env; 

} 

I relation OR predicate 

{predicate[l].tra = [relation.tm," or ",predicate[2].tm]; 
predicate[l].type = 

predicate [2]. in_env = predicate[l].in_env; 
relation. in_env = predicate[l].in_env; 

} 



relation 

: simple_expression rel_op simple_expression 
[relation.tm = rel_op.tm; 
simple_expression[l].in_env = relation.in_env; 
simple_expression[2].in_env = relation. in_env; 
relation, type = 

(simple_expression[l].type == "timer" II 
simple_expression[2].type = "timer" 

-> "timer" 

# simple_expression[l].type == "excp" II 
simple_expression[2].type == "excp" 

-> "excp" 
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# 



mi 



); 

rel_op.left_op = simple_expression[l].tm; 
rel_op.right_op = simple_expression[2].tm; 
rel_op.parent = relation.in_env("PARENT"); 
rel_op.opn_type = 

(simple_expression[l].type = "timer" II 
simple_expression[2].type = "timer" 

-> "timer_op" 

# "arithmetic" 

); 

} 

I simple_expression 
{relation.tm = simple_expression.tm; 
relation.type = simple_expression.type; 
simple_expression.in_env = relation.in_env; 

} 



simple_expression 

: INTEGER_LITERAL unit 

{simple_expression.tm = i2s(s2i(INTEGER_LITERAL.%text) 

* unit.value); 

simple_expression.type = "timer"; 

} 

I sign INTEGER_LITERAL 

{simple_expression.tm = [sign.tm,INTEGER_LrTERAL.%text]; 
simple_expression.type = ""; 

} 

I sign REAL.LITERAL 

{ simple_expression.tm = [sign.tm,REAL_LITERAL.%text]; 
simple_expression.type = ""; 

} 

IID 

{simple_expression.tm = ID.%text; 
simple_expression.type = 

(simple_expression.in_env(ID.%text^"CONSTRUCT") == "timer" 
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# simple_expression.in_env(ID.%text^"CONSTRUCT") 

); 

) 

I STRING.LITERAL 

{simple_expression.tm = STRING_LITERAL.%text; 
simple_expression.type = 

} 

I ’(’ predicate ’)’ 

{simple_expression.tm = ["(",predicate.tm,")"]; 
simple_expression.type = predicate.type; 
predicate.in_env = simple_expression.in_env; 

} 

I NOT ID 

{ simple_expression.tm = ["not ",ID.%text]; 
simple_expression.type = 

} 

I NOT ’(’ predicate ’)’ 

{simple_expression.tm = ["not (",predicate.tm,")"]; 

simple_expression.type = 

predicate.in_env = simple_expression.in_env; 

} 

I TRUE 

{simple_expression.tm = " true 
simple_expression.type = 

} 

I FALSE 

(simple_expression.tm = " false "; 
simple_expression.type = 

} 

I NOT TRUE 

{simple_expression.tm = [" not true "]; 
simple_expression.type = 

) 

I NOT FALSE 

(simple_expression.tm = " not false 
simple_expression.type = 

} 
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rel_op 
: ’<’ 



{rel_op.trn = 

(rel_op.opn_type == "dmer_op" 

-> ["PSDL_TIMER.\"<\T,rel_op.left_op,",",rel_op.right_op,") "] 
# [rel_op.left_op," < "^el_op.right_op] 

); 

) 

l’>’ 



{rel_op.tm = 

(rel_op.opn_type == "timer_op" 

-> ["PSDL_TIMER.V>\"(",rel_op.left_op,",",rel_op.right_op;’) "] 
# [rel_op.left_op," > "4'el_op.right_op] 

); 

} 



{rel_op.tm = 

(rel_op.opn_type == "timer_op" 

-> [”PSDL_TIMER.\"=V'(",rel_op.left_op,’’,",reLop.right_op,’’) "] 

# [rel_op.left_op," = " jel_op.right_op] 

); 

} 

I GTE 

{rel_op.trn = 

(rel_op.opn_type == "timer_op" 

-> ["PSDL_TIMER.\">=\"(",rel_op.left_op,",",rel_op.right_op,") "] 

# [rel_op.left_op," >= "4‘d_op.right_op] 

); 

} 

ILTE 

{rel_op.tm = 

(rel_op.opn_type == "timer_op" 

-> ["PSDL_TIMER.V'<=V'(",rel_op.left_op;’,",rel_op.right_op,") "] 
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# [rel_op.left_op," <= ’>el_op.right_op] 

); 

} 

INEQV 
(rel_op.tm = 

(rel_op.opn_type == "timer_op" 

-> ["PSDL_TIMER.VV=V(Vel_op.left_op,",'’,rel_op.right_op,") "] 

# [rel_op.left_op," /= ”,rel_op.right_op] 

); 

} 

I’:’ 

{rel_op.tm = 

(rel_op.right_op == "NORMAL" 

-> [rel_op.parent,"_SPEC.DS’>eLop.left_op,".IS_NORMAL "] 

# [rel_op.parent,"_SPEC.DS"^el_op.left_op, 
".IS_EXCEPTION('>el_op.right_op,") "] 

); 

} 



sign 



{sign.tm 



) 



{sign.tm = "- "; ) 
I 



(sign.tm = } 
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APPENDIX E. TRANSLATION TEMPLATES 



A. TL PACKAGE TEMPLATE 



with PSDL_SYSTEM; 
use PSDL_SYSTEM; 
package TL is 



type PSDL_EXCEPnON is (psdl_exqpl, psdl_excp2, ...,psdl_cxcpN); 
exq>l, excp2, excpN : exception; 



procedure Atomic_Driverl; 
procedure Atomic_Driver2; 

procedure Atomic_DriverJ; 



end TL; 



package body TL is 

Atomic procedures drawn from software base. 



PSDL operator specification packages. 



PSDL atomic operator driver procedures. 



end TL; 
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B. PSDL OPERATOR SPECIFICATION PACKAGE TEMPLATE 



This package template guides the translation of PSDL specifications into Ada 
packages. The packages contain only the data stream and timer instantiations tliat 
are local to Current_Operator. Current_Operator is the name listed in the header of 
the PSDL specification. Specification packages are produced only for composite 
operators. 

with Parent_Operator_SPEC; -- Current_Operator’s parent, 
use Parent_Operator_SPEC; 
package Current_Operator_SPEC is 



INPUT data stream instantiations. 



OUTPUT data stream instantiations. 



STATES data stream instantiations. 



DATA STREAM data stream instantiations. 



TIMER instantiations. 



end Current_Operator_SPEC; 
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C. PSDL ATOMIC OPERATOR DRIVER PROCEDURE TEMPLATE 



This template guides the construction of the procedure that is used to implement 
an atomic PSDL operator. It implements the Ada code necessary to simulate all of 
the control constraints on the operator. It also contains a procedure call to the code 
which implements the actual operator drawn from the software base. When imple- 
mented, it is these procedures that will serve as the interface between the static and 
dynamic schedules and the operators from the software base. 



with Current_Operator_SPEC; 

procedure Parent_Operator_Current_Operator is 



Data stream variable declarations. 



begin 

if DataJTrigger then 

Read input data streams, 
if Trigger_Condition then 



Current_Operator (Paramenter_List); — Atomic procedure call 



Control constraint implementations. 
Timer operations, 
exception operations, 
conditional output operations 

Unconditional output statements. 



end if; 
end if; 
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exception ^ 

when Adai_Exceptions => 

Write to output exception streams, 
when others => 

raise; -*• re*raise Ada exception if a cone^>onding PSDL exception not 

declared 



end Parent_Operator_Current_Operator; 
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